[16] RFR(XS): 8252037: Optimized build is broken

Christian Hagedorn christian.hagedorn at oracle.com
Thu Aug 20 09:36:53 UTC 2020


Hi Kim

On 20.08.20 10:57, Kim Barrett wrote:
>> On Aug 19, 2020, at 10:00 AM, Christian Hagedorn <christian.hagedorn at oracle.com> wrote:
>>
>> Hi
>>
>> Please review the following small patch which fixes the broken optimized build:
>> https://bugs.openjdk.java.net/browse/JDK-8252037
>> http://cr.openjdk.java.net/~chagedorn/8252037/webrev.00/
>>
>> There are actually two build issues as shown in the bug description.
>>
>> Thank you!
>>
>> Best regards,
>> Christian
> 
> I think the changes to parallelgc are contrary to the intent of the optimized build [1].  I think the
> bug here is that these counters are being conditionally printed under PRODUCT, but should
> be printed under ASSERT.  That is, 8232686 wasn’t quite right.  I guess nobody has done an
> optimized build in a while.

Yes, it does not seem to be built that often.

> 
> [1] Quoting myself from a different recent review thread:
> The purpose of "optimized" builds (as explained to me by one of its
> long-time proponents) is to have the performance characteristics of a
> release build (so no extra checks that affect performance or timing),
> but provide additional tools and data (printers, names, &etc) that we
> want to exclude from a release build for reasons of saving space or
> whatever. There's certainly lots of confusion around it though.

I see, thanks for explaining the purpose of the optimized build in more 
detail - it was indeed a bit confusing. Then it makes sense to revert 
these related changes to keep these counters under the ASSERT and guard 
the logging with an additional ifdef ASSERT instead to fix the build 
issues. I updated that in a new webrev (the optimized build was 
successful with it):

http://cr.openjdk.java.net/~chagedorn/8252037/webrev.01/

Best regards,
Christian


More information about the hotspot-dev mailing list