RFR: 8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders [v2]

Coleen Phillimore coleenp at openjdk.org
Sun Nov 6 23:09:54 UTC 2022


On Sun, 6 Nov 2022 22:50:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Okay but isn't that what should be expected? This is a flag to prevent a certain kind of classloader from deadlocking, so if we have that kind of classloader and the flag is disabled, then we should expect deadlock. Otherwise what will the failure mode be here? If we are introducing a new failure mode then it needs to be documented in the CSR request and possibly a Release Note.
>
> Coleen has reminded me that I am confused about what the workaround was doing - this code doesn't prevent deadlock, it prevents a LinkageError that would otherwise occur because the classloader has done something tricky (released the monitor) to prevent deadlock. So the correct behaviour here is proceed with the class loading and trigger the LinkageError in the other thread.

No, the expectation without this code is a LinkageError: dupicate class definition.  I just started the release-note subtask to describe this.  The expected behavior is that we don't wait, we just let the application load the class even though they've broken the lock.

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

PR: https://git.openjdk.org/jdk/pull/10832


More information about the core-libs-dev mailing list