RFR: 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing

[Ioi Lam]

On Fri, 7 May 2021 14:52:48 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> > > JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason.
> > 
> > 
> > This is a disturbing statement given the breakage in the CI. Has sufficient testing
> > been done to determine whether these other two bugs continue to happen or not.
> > I'm really starting to wonder why the original fix wasn't backed out on Wednesday.
> 
> > Hi Yumin,
> > So there are three "exit" paths covered by this:
> > 
> > * System.exit/halt
> > * last thread terminates VM
> > * -Xshare:dump
> > 
> > so that seems reasonable.
> > But I see a pre-existing problem that is now worse with this change. In JavaThread::invoke_shutdown_hooks we have this code:
> > // We could get here with a pending exception, if so clear it now.
> > if (this->has_pending_exception()) {
> > this->clear_pending_exception();
> > }
> > but that appears after the call to link_and_cleanup_shared_classes, so if in fact there is a pre-existing exception we will return from link_and_cleanup_shared_classes at the first CHECK (which is now on the newly moved code).
> > In order to get the current crashes fixed we can address the exception issue in a follow up bug.
> 
> Hi, David
> Thanks for review. Yes, if the regeneration of holder classes returned with first CHECK, the exception is cleaned here. So the dump will be finished without finishing the original functions which link_and_cleanup_shared_classes intends to do. This requests LambdaFormInvokers::regnerate_holder_classes suppress all exceptions except for OOM (which exit directly from VM). This part needs an overall checking for various cases. Thanks for catching this.
> 
> Yumin

I created https://bugs.openjdk.java.net/browse/JDK-8266770 "Clean pending exception before running dynamic CDS dump"

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

PR: https://git.openjdk.java.net/jdk/pull/3910