RFR(XS): 8024008: Nashorn V8 (Crypto) benchmark crashes with small CodeCache size
albert.noll at oracle.com
Tue Sep 10 00:03:43 PDT 2013
thanks for looking at this. I checked all call sites of
'make_not_entrant()' and 'make_zombie()'. I do not see any problems.
The worst thing that can happen is that an nmethod for which the call
returns fals gets removed later than expected.
I updated the comment and did some minor code refactoring.
Also I think that it is worth considering to backport this change, since
the bug can appear any time
the code cache fills up. If that bug appears, it is extremely hard to
reproduce and debug.
Here is the updated webrev.
On 09.09.2013 19:47, Vladimir Kozlov wrote:
> Several places in sources do not check returned result of
> make_not_entrant_or_zombie(). And they may assume that method marked
> as non-entrant, for example, because before we returned 'false' only
> when an other thread already changed the state to one we need.
> Can you check all call sites to make sure they work correctly with
> this change?
> On 9/9/13 6:59 AM, Albert Noll wrote:
>> thanks for reviewing this patch.
>> Many thanks in advance,
>> The state of nmethods that are currently locked by the VM must not
>> Some operations such as setting ICs (e.g.,
>> rely on this fact. 'nmethod::make_not_entrant_or_zombie does not
>> make this
>> Do method state unchanged of nmethod is locked by the VM.
>> Testing: Run Octane benchmarks on top of Nashorn with small code
>> cache size (16m).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev