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

[Chris Plummer]

Hi Albert,

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.

cheers,

Chris

On 10/9/13 10:21 AM, Vladimir Kozlov wrote:
> 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