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

[John Coomes]

David Holmes (David.Holmes at oracle.com) wrote:
> John Coomes said the following on 03/04/11 06:14:
> > Coleen Phillimore (coleen.phillimore at oracle.com) wrote:
> >> Summary: Fix compilation error(s)
> >>
> >> Also fix new random gcc compiler error in os::free() in gcc 4.4.1.
> >>
> >> open webrev at http://cr.openjdk.java.net/~coleenp/7021653/
> >> bug link at http://bugs.sun.com/view_bug.do?bug_id=7021653
> >>
> >> 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.

-John