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

[Christian Hagedorn]

On 21.08.20 01:57, Kim Barrett wrote:
>> On Aug 20, 2020, at 7:38 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>
>>
>>> 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.
>>> [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.
>>
>> Ultimately it's GC team call, but counters are extensively used in optimized build. It this respect, it's perfectly fine to expose add_obj_count and add_obj_bytes in optimized build.
>>
>> Best regards,
>> Vladimir Ivanov
> 
> As a non-user of optimized builds, I don’t have any vested interest in this
> question one way or the other.  If people who do use it are okay with, or even
> prefer having these counters in such builds, I’m not going to object.  But I
> think it makes the distinguishing characteristics of an optimized build and how
> to categorize and conditionalize bits of code even harder and more confusing
> than it already is.

Thanks to all for sharing their views. It seems that all are fine with 
both versions. Since the counters were originally meant to be available 
only in non-optimized builds with ASSERT and due to the reasons stated 
above I will go with the second version to exclude the introduced 
logging of JDK-8232686 in optimized builds:

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

Best regards,
Christian