Request for review (xs) 7021653: Parfait issue in hotspot/src/share/vm/oops/methodDataOops.hpp

Coleen Phillimore coleen.phillimore at
Thu Mar 3 14:37:17 PST 2011

On 3/3/2011 4:19 PM, John Coomes wrote:
> David Holmes (David.Holmes at wrote:
>> John Coomes said the following on 03/04/11 06:14:
>>> Coleen Phillimore (coleen.phillimore at wrote:
>>>> Summary: Fix compilation error(s)
>>>> Also fix new random gcc compiler error in os::free() in gcc 4.4.1.
>>>> open webrev at
>>>> bug link at
>>>> Tested on windows and solaris 64 bit (actually tested with an assert
>>>> that the old calculation == new one).
>>> %x expects an unsigned value, so better to cast to uintptr_t (a total
>>> nit, but gcc is becoming increasingly nit-picky).  Other than that,
>>> looks good.
>> Agreed on both counts. It's already pretty unpleasant that when using
>> PTR_FORMAT we have to cast pointer types to intptr_t, but if gcc gets
>> even pickier we'll have to step through all those casts and change them
>> to uintptr_t. :(
>> Maybe it's time to revisit the attempt to use %p? We should have a good
>> idea which of our compilers add the 0x and which do not, and we should
>> be able to specify a build flag to select it. (Not that I'm volunteering
>> :) )
> We could fairly easily use compiler-specific PTR_FORMAT macros to deal
> with the leading 0x, 0-padding, etc.  That would help, except for null
> pointers.  With gcc/glibc, %p prints '(nil)' for null values.  Ugh.
> Given that, I don't see a way to get consistent output across
> platforms with %p.

This is a bigger project than it appears, maybe someone can do this when 
the next gcc error message comes along.

> -John

More information about the hotspot-runtime-dev mailing list