RFR(XXS) 8057750: CTW should not make MH intrinsics not entrant

[Gilles Duboscq]

Hello,

In graal we went down a slightly different road to solve this issue:
instead of trying to find all the possible path through which the VM
could try to make those intrinsics non-entrant we just re-compile them
when we need to [1,2].

While the assert that was added in 8056154 should make it easier to
spot problems, I think it would be more robust to just add code that
recompiles the intrinsic such that we don't just crash the VM when we
could actually do something about it.
Both approaches are probably complementary.

-Gilles

[1] http://hg.openjdk.java.net/graal/graal/rev/b7a1ece4f07b
[2] http://hg.openjdk.java.net/graal/graal/rev/fefb82b01d6f

On Mon, Sep 8, 2014 at 8:52 AM, Albert <albert.noll at oracle.com> wrote:
> Hi Igor,
>
> why are we not allowed to make MH intrinsics not entrant just after we've
> compiled them?
> Is this requirement specific to CTW?
> We do not seem to have such a check in sweeper.cpp, i.e., MH instrinsics are
> made not-entrant
> in NMethodSweeper::possibly_flush().
>
> Best,
> Albert
>
>
> On 09/08/2014 08:02 AM, Igor Veresov wrote:
>>
>> Follow-up to 8056154. CTW makes methods that were just compiled not
>> entrant, which in case of MH intrinsics violates the invariant.
>>
>> Webrev: http://cr.openjdk.java.net/~iveresov/8057750/webrev.00/
>>
>> Thanks!
>> igor
>
>