RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie
vladimir.x.ivanov at oracle.com
Tue Nov 5 10:57:24 PST 2013
I take my words back about sweeper.
The method is invalidated during class redefinition because it is
dependent on redefined class
On 11/5/13 5:11 PM, Albert Noll wrote:
> Hi Vladimir,
> I have a question: the sweeper calls make_not_entrant() on a nmethod
> only after the nmethod
> has been in the code cache for at least 10 occurrences of a safepoint
> (time_since_reset in sweeper.ccp).
> Couldn't it also be that we mistakenly call the function
> make_not_entrant() from somewhere else and that this is the root cause
> of the error?
> On 11/05/2013 01:47 PM, Roland Westrelin wrote:
>> Hi Vladimir,
>>> There's a race between compiler thread during method registration and
>>> sweeper: sweeper can invalidate a nmethod which hasn't been installed
>>> Consider the following scenario:
>>> - new nmethod(...)
>>> - invalidates newly allocated nmethod and patches VEP to call
>>> - tries to unlink it, but method()->from_compiled_entry() !=
>>> verified_entry_point() since nmethod hasn't been installed yet
>>> - installs already invalidated nmethod
>>> Calling corresponding Java method will lead to infinite loop: VEP of
>>> the compiled method calls handle_wrong_method and call site
>>> resolution returns the very same compiled method.
>> Does that mean StressNonEntrant is broken?
>>> The fix is to grab a lock after nmethod is allocated in the code
>>> cache and check that it hasn't been already invalidated by the
>>> sweeper before proceeding. Sweeper already synchronizes on a nmethod
>>> before invalidating it.
>> Would another fix be to have the sweeper check that the method was
>> made ready to execute before it attempts to make it not entrant?
>> i.e. nmethod->method()->code() == nmethod
More information about the hotspot-compiler-dev