RFR: 8218974: Free GC native structures in nmethod::flush

Per Liden per.liden at oracle.com
Mon Feb 18 06:44:19 UTC 2019

Hi Erik,

On 02/14/2019 12:55 PM, Erik Österlund wrote:
> Hi,
> An nmethod goes from being is_alive() to being !is_alive() and 
> eventually being freed in nmethod::flush. Native structures for nmethods 
> are freed in nmethod::flush when we free the nmethod. Except for a few 
> things, including GC data. This enhancement proposes to fix that to make 
> the life cycle of nmethods and their native data more intuitive.
> In particular ZGC has per-nmethod data. The data is removed when 
> unlinking nmethods, as opposed to when they are deleted. This is a bit 
> awkward and makes things more difficult than they need to be. This patch 
> adds a new CollectedHeap::flush_nmethod() function. In there ZGC deletes 
> its attached GC data.
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8218974
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8218974/webrev.00/

Do we need to introduce a new flush_nmethod()? Would it instead be 
possible to move/adjust where unregister_nmethod() is called to get the 
same effect? When just looking at the API, the relationship between 
unregister and flush is not super obvious. Determining which one will be 
called first and what a GC allowed/supposed to do in each of them kind 
of requires you to inspect the call-sites.


More information about the hotspot-gc-dev mailing list