Request review: 4360113: Evict nmethods when code cache gets full

[Eric Caspole]

4360113: Evict nmethods when code cache gets full

http://cr.openjdk.java.net/~ecaspole/4360113/

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  
state.

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,
Eric