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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Oct 9 10:21:16 PDT 2013


Albert,

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

Thanks,
Vladimir

On 10/8/13 10:18 PM, Albert Noll wrote:
> Hi,
>
> could I have a review for this small patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8023191
> webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.00/
> <http://cr.openjdk.java.net/%7Eanoll/8023191/webrev.00/>
>
> Problem: OSR methods are not removed from code cache to free space.
> Solution: Remove OSR methods from code cache. OSR methods c an be made
>                 not-entrant and are then removed from the code cache
> likenon-OSR
>                 methods. Other parts in the code (e.g.,
> deoptimization.cpp:1547) already make
>                 OSR methods not-entrant.
>
> Testing: Passed JPRT; I'll also run specjvm and nashorn to see if there
> is an impact on performance.
>
> Many thanks in advance,
> Albert


More information about the hotspot-compiler-dev mailing list