Stack walking performance issue

coleen.phillimore at coleen.phillimore at
Tue Mar 19 15:00:27 UTC 2019

Hi, Thanks for the diagnosis yesterday.  With concurrent class unloading 
in 13, you also need to trigger_cleanup at some GC point.

The triggering and/or cleanup of this table was put in 
SystemDictionary::do_unloading() for convenience, but really belongs 
somewhere after the weak references are cleared (maybe need a count of 
references cleared and their own weak OopStorage), especially if the 
stack walk API is used a lot.


On 3/18/19 5:53 PM, Aleksey Shipilev wrote:
> On 3/18/19 10:32 PM, Amir Hadadi wrote:
>> If anyone is willing to build an Open JDK with this fix I can give it a spin.
> I think you'd want to build the OpenJDK on your target system, that would avoid compatibility woes
> (for example, glibc and other library dependencies). Short example:
>   $ hg clone zgc-jdk11u
>   $ cd zgc-jdk11u
>   $ ./configure # this might fail the first time, install dependencies, etc
>   $ make images
>   <should complete fine>
> Add call to ResolvedMethodTable::unlink() to ZHeap::mark_end. You'd probably need to include
> prims/resolvedMethodTable.hpp too.
>   $ make images
>   $ build/linux-x86_64-normal-server-release/images/jdk/bin/java
> -Aleksey

More information about the zgc-dev mailing list