RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache

[John Rose]

On Oct 9, 2013, at 10:21 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Changes are fine but you need more testing.
> 
> Run full CTW too and all jtreg tests from Hotspot and jdk (run jdk tests with -Xcomp and without it).
> 
> Also the bug report has link to test (jittest). Can you build and run it too to see if it solves the problem with small codecache? It fills codecache with osr nmethods.
> 
> It is very delicate matter. There was a reason we did not remove OSR nmethod until corresponding klass is unloaded (yes, deoptimization can make it non-entrant). Unfortunately I don't remember it. May be John know.

IIRC we introduced OSR n-methods long before we figured out the right way to do sweeping and n-method flushing.  Managing regular n-methods requires lots of tricks, and OSR n-methods have always been subject to different rules.  I suspect the current rules for OSRs are conservative simply to avoid interactions with the sweeper.

We need to clarify the rules for determining n-method liveness and storage management so there is less mystery.  We are making progress on this.

Along the same line, I would like to see less special-purpose machinery for managing OSR code, and an emphasis on allowing Java methods to have multiple variant compilations, with normal and OSR modes being special cases.  Other special cases might be "optimized but re-profiling" or "partially optimized and suitable for OSR or deopt" or "compiled for a coprocessor" or "loop-customized for a given closure".  In some cases the variant is a "plug compatible" replacement for the main variant; in some cases it is a strength reduced version (loop customization); and in some cases it is special-purpose code (for OSR entry or GPU execution).

> Non of inline caches are pointing to OSR nmethods since it is called only from Interpreter. There is transition phase at the start of OSR nmethod when it calls runtime to convert interpreter frame to compiled frame. And method has separate field for osr nmethods.

Extending the point above, there should (at most) one field in a methodOop that points to a linked list of n-method versions, with an open-ended set of possibilities.  Most methods have no n-methods at all, so this has interactions with density.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131009/36be77e2/attachment-0001.html