RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache
chris.plummer at oracle.com
Wed Oct 9 12:24:17 PDT 2013
I recall having experimented with this same change and started getting
crashes when using a small code cache and inducing a lot of sweeping and
flushing. This was earlier in the year, and I also had made a couple of
other changes that may have been the cause of the crashes, but I was
highly suspect of this one. I'd suggest running Nashorn with the v8
benchmark and SpecJVM98 with about 3800k codecache. Also use -client if
making the codecache this small. This is roughly what I was doing when I
saw crashes, but it was long ago and I forget all the details. You may
want to try other codecaches of similar sizes. The key is making sure it
is small enough to induce some performance regression (maybe 10% to 50%)
so you know the codecache flushing code is being heavily stressed.
On 10/9/13 10:21 AM, Vladimir Kozlov 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. 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.
> On 10/8/13 10:18 PM, Albert Noll wrote:
>> 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/
>> 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
>> 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,
More information about the hotspot-compiler-dev