RFR: 8218969: Free JVMCI native structures in nmethod::flush
tom.rodriguez at oracle.com
Thu Feb 14 21:11:04 UTC 2019
Doug Simon wrote on 2/14/19 12:11 PM:
> Hi Eric,
> This seems sensible to me and I cannot recall any special reason it wasn’t done this way to begin with. Tom, do you have any recollections about this?
It was originally plugged into the nmethod::oops_do machinery so it
happened earlier and I think when we converted to using jweak we kept
the existing structure to release those resources more promptly. The
installed_code reference in particular often becomes null very early so
releasing it earlier seemed like better hygiene. I don't think it
changes the way anything behaves to do it later but there will be more
jweaks apparently alive.
I noticed the assert was removed from the clear methods. I would prefer
to either update them on the CodeCache_lock to match their single caller
or simply inline them directly into flush.
>> On 14 Feb 2019, at 12:08, Erik Österlund <erik.osterlund at oracle.com> wrote:
>> 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 JVMCI handles, that are freed already when becoming !is_alive (and some logic to deal with this potentially happening twice for a given nmethod), and finally asserting during flush that it was already cleared.
>> This enhancement proposes to treat these JVMCI handles like we treat any other native structure and simply free it in nmethod::flush, when we free the nmethod, so that the nmethod and handles have a 1:1 mapping for their life cycles.
More information about the hotspot-compiler-dev