JDK-8028001 : Add new nmethod state "created" for newly allocated not yet installed nmethod
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,9,10
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2013-11-07
  • Updated: 2023-07-21
  • Resolved: 2023-07-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11Resolved
Related Reports
Duplicate :  
JDK-8043070 - nmethod::verify_interrupt_point() shouldn't enter safepoint
Relates :  
JDK-8043070 - nmethod::verify_interrupt_point() shouldn't enter safepoint
Description
Add new nmethod state "created" for newly allocated not yet installed nmethod.

Right now, nmethod is created in "alive" state and it's hard to detect whether nmethod is already installed or not.
Comments
Thank you, Igor, for the information and also for the suggestions! Having a description of how things work is always very helpful.
07-08-2014
Here are some notes I have about the locks and the machinery involved in all of this. They are most likely incomplete. Locks: - CodeCache_lock, no_safepoint_check. All kinds of operations on CodeCache structure, blob insertion, deletion - Patching_lock, no_safepoint_check. Any kinds of patching, including ICs. Also guards nmethod state transitions. - CompiledIC_lock, can safepoint. Groups reads and writes to ICs. Note that writes to ICs take Patching_lock. - VtableStubs_lock, InlineCacheBuffer_lock can safepoint. Taken under CompiledIC_lock. - Compile_lock, can safepoint. Can be taken under MethodCompileQueue_lock. Guards metadata modification (for example system dict). - MethodCompileQueue_lock, can safepoint. nmethodLocker: - stops sweeper from initiating nmethod state transitions. Used in the following contexts: - in nmethod::make_not_entrant_or_zombie() used to take sure it's not flushed while the method is run. SharedRuntime::resolve_sub_helper() is funky. There is nothing guaranteeing that callee_nm stays live thru the whole procedure. SharedRuntime::handle_ic_miss_helper() looks like it has problems as well. Possible solutions for the cleanup: - avoid obtaining direct pointers to nmethod. Try to do it with returning nmethodLocker objects instead, and guaranteeing that these were created under conditions when the state transition {in_use, not_entrant} -> zombie is impossible. - make_zombie() should abort if anybody else holds the lock. - release_method() should do the same since it's possible to lock a zombie method. - compute_monomorphic_entry() should get nmethod as an argument instead of reloading it from method->code(). - IC patching *and* checks of whether the nmethod is in the "in_use" state should happen under the Patching_lock. If the the callee nmethod is not in the "in_use" state, it should not be referenced by IC. This will avoid the need of > 2 sweeps to make sure all ICs are cleared. It should also allow to get rid of extra sweep pass to reclaim zombies. There should be no ICs pointing to zombies, period. That'd be fatal.
06-08-2014
There is another may be better way to approach this. It could be possible to use nmethodLocker to prevent the alive -> not_entrant transition during installation.
06-08-2014