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

[Kim Barrett]

> 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.