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.
cheers,
Per
More information about the hotspot-gc-dev
mailing list