[9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang

[David Chase]

On 2014-05-08, at 11:04 PM, David Holmes <david.holmes at oracle.com> wrote:

> On 9/05/2014 7:08 AM, David Chase wrote:
>> On 2014-05-07, at 6:38 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> In memnode.cpp use INTX_FORMAT instead of %" PRIdPTR.
>> 
>> Fixed.
>> 
>> I looked into the issue of changing PTR_FORMAT to be a platform-dependent variation on %p;
>> however it appears to be not-possible to do this without changing with some formatted pointer
>> outputs (I've tried hard not to change outputs at all, though there have been some changes at
>> reviewer request), and because this may affect user-visible outputs (e.g., parsing GC logs) I'd
>> rather not do it as part of this giant patch -- if there's a problem, this is a big revert.
> 
> But surely the p2i + INTPTR_FORMAT change is an even bigger revert! Unless you propose to keep using PTR_FORMAT even with p2i ? (In case it is half as big a revert but still big).

It depends on how you measure the size of the change/revert.  My goal, undermined slightly by Vladimir K insisting on INTPTR_FORMAT (%016x or %08x) where we had previously just used %x in some compiler code, was to have ZERO changes in the output after this cleanup.  The intent is to only deal with format compilation warnings across all platforms, with a good bit of future-proofing and honesty-about-our-warnings thrown in for good measure.  Wholesale change to PTR_FORMAT guarantees a change to output on most platforms.

I don't think we would ever do a full revert.  Anywhere that we print pointers that end up in the hands of users, in particular users with automated log parsers, we need to be careful about gratuitous change.  We're in the Java business, after all, if our customers wanted lots of platform-to-platform gratuitous variation, they'd use C++ instead.

So any revert would be incremental; once we make PTR_FORMAT work across platforms for actual pointers, if someone is working on some of our own code and wants to get rid of INTPTR_FORMAT and p2i, they can.

> Put another way, once you've done the p2i+INTPTR_FORMAT change, what incentive is there to fix the %p issue and revert everything you just changed? This seems like a now-or-never fix to me.

The incentive is that our source code is quite ugly, and we'd like to make it prettier when we work on it.  

David