Request review: 4360113: Evict nmethods when code cache gets full
eric.caspole at amd.com
Mon Dec 14 18:06:23 PST 2009
4360113: Evict nmethods when code cache gets full
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 hiding the
methodOop's ref to the nmethod in the new _saved_code field. Then
execution resumes. After inline cache cleaning, callers will have to
go back to the methodOop to get the verified entry point.
At that point, the methodOop's _code field is restored from the
_saved_code field and the methodOop/nmethod go back to their normal
If a method so marked is not 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.
In my testing, this allows the program to quickly resume normal
operation with no noticeable performance degradation.
Thanks for your comments,
More information about the hotspot-compiler-dev