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

[Igor Veresov]

Hi Albert,

On Sep 7, 2014, at 11:52 PM, 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?

It is due to the fact that they are frameless. Compiled code cannot call them in their interpreter form, because the intrinsic may call another compiled method  which involves doing c2i and then i2c on the same frame and that doesn’t work. At the time a compiled callsite links with the MH intrinsic method, there must be a compiled version of it. Moreover, it must never go away because if it does, the IC will be cleared and then relinked with the c2i adapter, which will cause failures because of the mentioned c2i->i2c composability problem. So, within the existing framework, the invariant is that an MH intrinsic must always have both interpreted and compiled forms.

> Is this requirement specific to CTW?

No, it’s a general invariant. For CTW it’s actually less relevant, because it’s unlikely anybody will try to actually call the intrinsic, but I’d rather always enforce the invariant (in theory once a method is published it might be linked to).

> We do not seem to have such a check in sweeper.cpp, i.e., MH instrinsics are made not-entrant
> in NMethodSweeper::possibly_flush().

They are not, the sweeper doesn’t flush methods that are is_native(), and MH intrinsics have the native bit set.

igor

> 
> 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
>