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

[Vladimir Ivanov]

>> [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.
> It's been a long time, low-priority issue to try and disentangle the 
> bunch of  "tweaks" that optimized builds bring, so they can be turned on 
> and off individually. This would allow us to scrap optimized builds, 
> which often bit-rot since they are seldom used. Unfortunately, the low 
> priority of this means that no progress at all has been made for I think 
> several years. :-( There is a JBS issue somewhere which outlines what 
> kind of work is needed.

This thread is probably not the best place to discuss it, but I don't 
see why wrapping the code and expose it as optional JVM feature will 
help avoid bit-rot.

It can improve the code itself (choosing between "#ifdef ASSERT" and 
"#ifndef PRODUCT" is error-prone), but it won't make it built more 
frequently by itself.

IMO the root cause is that optimized configuration is not built as part 
of any regular testing. And irrespective of how the code is shaped, it's 
required step to avoid bit-rot.

Best regards,
Vladimir Ivanov