On 15/09/2023 5:00 pm, Simone Bordet wrote:
David,
On Thu, Sep 14, 2023 at 4:33 AM David Holmes <david.hol...@oracle.com> wrote:
I've created a draft PR here:
https://github.com/openjdk/jdk/pull/15732
can you apply that patch, build and re-test? Hopefully that will show
which thread is doing the missing initialization.
We have attached the logs to the pull request above.
Seems like a classic deadlock:
Indeed it does. The reason this was not visible in the thread dump is
that we have not reached the point of <clinit> execution for
MutableHttpFields, but are blocked trying to get the class
initialization lock for a superclass/interface to ensure it is
initialized first.
'[8.061s][debug][class,init] Thread ForkJoinPool-1-worker-1 is
initializing org.eclipse.jetty.http.HttpFields'.
...
'[8.113s][debug][class,init] Thread ForkJoinPool-1-worker-2 is
initializing org.eclipse.jetty.http.MutableHttpFields'.
'[8.113s][debug][class,init] Thread ForkJoinPool-1-worker-2 waiting
for initialization of org.eclipse.jetty.http.HttpFields by thread
ForkJoinPool-1-worker-1'.
...
'[8.117s][debug][class,init] Thread ForkJoinPool-1-worker-1
recursively initializing org.eclipse.jetty.http.HttpFields'.
'[8.117s][debug][class,init] Thread ForkJoinPool-1-worker-1 waiting
for initialization of org.eclipse.jetty.http.MutableHttpFields by
thread ForkJoinPool-1-worker-2'.
It is peculiar that we already get this deadlock for the same classes.
Perhaps we are using a pattern in the code that makes it more likely to happen?
Perhaps. I don't know the jetty code at all so you would need to go back
to them with these findings. If two classes have a dependency on each
other this way then you would normally expect there to be a preferred
"entry point" so that initialization will always occur in the same
order. But it is a fragile design where a superclass/interface uses its
own subclass in its static initialization.
Glad this helped expose the problem.
Cheers,
David
-----
Thanks!
