RFR: 8322282: Incorrect LoaderConstraintTable::add_entry after JDK-8298468

[Aleksey Shipilev]

On Mon, 18 Dec 2023 22:33:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Problem is without a proper regression test we only know that this change fixes one problem, but we don't know if it has any unexpected side-effects that the bug has been masking. I want a much better understanding of the bug before integrating the fix.

>From the strategical point of view, I understand the desire to understand the compile (mis)behavior better. But I think it is not a great tactical move, as it is not directly relevant to the fix.

Here is how I look at this problem:
 1. [JDK-8298468](https://bugs.openjdk.org/browse/JDK-8298468) was supposed to be a cleanup. In other words, it is was supposed to be behavior-preserving.
 2. We have identified the hunk in the original changeset that violates the behavior-preserving property, which looks like a simple mistake.
 3. This fix restores the original behavior before [JDK-8298468](https://bugs.openjdk.org/browse/JDK-8298468) in this hunk.

The good questions to ask ourselves at this point are: _Would any of these facts change as the result of the deeper understanding of how exactly this mistake breaks the compiler? Would there be a situation where we decide that going with this fix is not a good idea? Would we be deeply investigating the implications of this mistake if it was caught during code review, instead of just fixing it and moving on?_ I think the probability of answering "yes" to all these questions is very low. In fact the only way I see that happening if we discover that the whole [JDK-8298468](https://bugs.openjdk.org/browse/JDK-8298468) is wrong and needs to be backed out.

But if we (I argue, reasonably) answer "no" to these questions, then holding off from integrating this fix before we gain more understanding how exactly it breaks compiler gains us nothing. But it delays fixing JDK 23, 23, 21 sooner, which is even more important when there is an actual _customer-visible breakage_ reported on JDK 21.

In other words, could there be a situation where this mistake exposes some deeper problem in Hotspot? Yes, that might happen, but it changes nothing about the actual behavior-breaking impact of [JDK-8298468](https://bugs.openjdk.org/browse/JDK-8298468) this point fix resolves. One can always follow-up deeper on these problems by reverting the fix in mainline and then investigating. I would further suspect that this is a kind of "garbage in, garbage out" scenario, where we report wrong metadata to the compiler, and it breaks in fascinating ways. We know it happens in other funky scenarios like feeding the unverifiable bytecode, for example.

So, I propose we do not quibble over this fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17140#issuecomment-1862428839