[16] RFR(XS): 8252037: Optimized build is broken
Kim Barrett
kim.barrett at oracle.com
Thu Aug 20 23:21:34 UTC 2020
> On Aug 20, 2020, at 7:48 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>
>>> [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.
The bug Magnus is looking for is JDK-8183287.
But I agree that splitting the various pieces up into separately conditionally compiled chunks
under their own specific control macros doesn’t fix the bit rot problem. If anything, it makes
it worse. We could avoid bit rot in the optimized builds by just adding a build for it to the CI.
Having N separate macros just means you need to turn them all on or all off (at least), and
if you are actually paranoid about it you need to do all combinations thereof (yeah right, that’s
not going to happen).
More information about the hotspot-dev
mailing list