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