[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