Bug ID: JDK-4360113 Evict nmethods when code cache gets full

Versions (Unresolved/Resolved/Fixed)

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 6	JDK 7	Other
6u21Fixed	7Fixed	hs17Fixed

Presently the VM is started with a fixed limit on the size of
generated code. When classes gets unloaded, the corresponding
nmethods gets flushed from the code cache.

If the code cache limit is reached, no more compilation occurs,
even is class unloading occurs at a future point. For most
programs this is a non-issue, but this failure has been observed
for the Cloudscape big app, which compiles SQL->Java on the fly
without ever unloading code.

A reasonable solution would be to write the currect GC invocation
count in an nmethod whenever it is seen on the stack (already done
for non-reentrant methods). If the code cache fills up, we can
force deoptimization and flushing of the nmethods with the lowest
GC counts.

steffen.grarup@eng 2000-08-07

An improved version of the scheme above would be to force frequent
safepoints when the code cache get close to the limit. At each
safepoint we could write the current GC invocation count in all
nmethods seen on stack. This would greate reduce the risk of
flushing a hot non-allocating nmethod.
steffen.grarup@eng 2000-10-16

SUGGESTED FIX The fix is contributed by Eric Caspole ###@###.###. http://cr.openjdk.java.net/~ecaspole/4360113/webrev.06/webrev
29-01-2010
PUBLIC COMMENTS Eric Caspole wrote: In this change, under a flag and off by default, when compilers notice the code cache is getting full, they will call a vm op that calls new code that attempts to speculatively unload the oldest half of the nmethods (based on the compile job id) by setting the methodOop's _code field to null, and managing a list of methods disconnected in this way by linking the disconnected nmethods by the nmethod's new _saved_nmethod_link field. Then execution resumes. After inline cache cleaning, callers will have to go back to the methodOop to get the verified entry point, or request recompilation. At that point, the disconnected methodOop's _code field can be restored by looking up the saved nmethod ptr in the nmethod _saved_nmethod_link list, and the methodOop/nmethod go back to their normal state. If a disconnected nmethod is not restored and called by the second sweep cycle after the one where forced unloading happened, the nmethod will be marked non-entrant and got rid of by normal sweeping. That gives the app a few seconds to make progress and call its hottest methods. We chose to target the oldest half of nmethods due to a customer experience with a long-running app server, and despite multiple redeployments of the same web app, something was preventing old instances of the web app from ever getting unloaded. In that case, they ran into the code cache full problem so the most recent redeployment was running interpreter only. We have also observed that for many applications a lot of methods get compiled and used during the startup phase that are never used again. In this change there is also a timer based backoff, default of 30 seconds, so that if the normal state of the app is constantly triggering unloading, the unloading will stop and it will fall back to the existing situation of disabling the compiler.
29-01-2010
EVALUATION ChangeSet=http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5f24d0319e54,ChangeRequest=4360113
29-01-2010
EVALUATION Worth fixing. david.stoutamire@Eng 2000-08-12 Putback changes listed in the Comments section to Ladybird. The more general approach can wait for Merlin. Committing bug to Merlin. steffen.grarup@eng 2000-10-22
12-08-2000

Relates :	JDK-6976372 - # assert(_owner == Thread::current()) failed: invariant
Relates :	JDK-6957825 - "CodeCache is full. Compiler has been disabled" after 23 hours
Relates :	JDK-6935466 - new CodeCache flushing code is not guarded by the flag
Relates :	JDK-6928717 - HS17 fails to build with SS11 C++