RFR(XS): 8024008: Nashorn V8 (Crypto) benchmark crashes with small CodeCache size
albert.noll at oracle.com
Tue Sep 10 05:52:34 PDT 2013
the current version causes a serious performance regression.
I have to figure out what's wrong.
On 10.09.2013 09:03, Albert Noll wrote:
> Hi Vladimir,
> 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