Hi Coleen,
On 16/12/2019 9:41 pm, [email protected] wrote:
Summary: Start ServiceThread before compiler threads, and run nmethod
barriers for zgc before adding to the service thread queue, or posting
the events on the java thread queue.
I can't comment on most of this but the earlier starting of the service
thread has some concerns:
- there is a lot of JDK level initialization which now will not have
happened before the service thread is started and it is far from obvious
that all possible initialization dependencies will be satisfied
- current starting of the service thread in Management::initialize is
guarded by "#if INCLUDE_MANAGEMENT", but now you are starting the
service thread unconditionally for all builds. Hmm just saw your latest
comment to the bug report - so the service thread is now (for quite some
time?) being used for other than management tasks and so should always
be present even if INCLUDE_MANAGEMENT is not enabled. Is that sufficient
or are there likely to be other changes needed to actually ensure that
all works correctly e.g. any code the service thread executes that is
only defined for INCLUDE_MANAGEMENT will need to be compiled out explicitly.
- the service thread and the notification thread are (were?) closely
related but now started at completely different times
The bug report states the problem as:
"The graal crash is because compiled_method_load events are added to the
ServiceThread's deferred event queue before the ServiceThread is created
so are not walked to keep them from being zombied."
so why isn't the solution to ensure the deferred event queue is walked?
I'm not clear how starting the service thread relates to walking the queue.
Thanks,
David
See bug for description of the problems found with the new Zombie.java
test.
open webrev at http://cr.openjdk.java.net/~coleenp/2019/8235829.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8235829
Ran tier1 all platforms, and tier2-8 testing, as well as rerunning
original test failure from bug
https://bugs.openjdk.java.net/browse/JDK-8173361.
Thanks,
Coleen
