United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4360113 Evict nmethods when code cache gets full
JDK-4360113 : Evict nmethods when code cache gets full

Details
Type:
Bug
Submit Date:
2000-08-07
Status:
Resolved
Updated Date:
2013-11-01
Project Name:
JDK
Resolved Date:
2010-02-09
Component:
hotspot
OS:
solaris_2.5.1
Sub-Component:
compiler
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.3.0
Fixed Versions:
hs17 (b09)

Related Reports
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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

                                    

Comments
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
                                     
2000-08-12
EVALUATION

ChangeSet=http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5f24d0319e54,ChangeRequest=4360113
                                     
2010-01-29
SUGGESTED FIX

The fix is contributed by Eric Caspole ###@###.###.

http://cr.openjdk.java.net/~ecaspole/4360113/webrev.06/webrev
                                     
2010-01-29
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.
                                     
2010-01-29



Hardware and Software, Engineered to Work Together