RFR(S) 8056154: JVM crash with EXCEPTION_ACCESS_VIOLATION when there are many threads running

[Vladimir Kozlov]

On 9/4/14 11:30 PM, Igor Veresov wrote:
> You’re right, it doesn’t make a lot of sense to check it in compiledIC. I removed it.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/8056154/webrev.01

Looks good.

>
> However you brought up another big problem (which deserves it’s own CR, may be there is one already): what should we do when the code cache is full. We may end up with a situation when we have to link with an MH intrinsic, but it was created after we switched the compilers off completely. In which case we’ll start doing this c2i -> i2c dance again that will fail.

I think, it should be fine since MH are compiled as adapters, regardless CodeCache usage.
See compileBroker.cpp at lines 1377:

   // do the compilation
   if (method->is_native()) {
     if (!PreferInterpreterNativeStubs || method->is_method_handle_intrinsic()) {
       // To properly handle the appendix argument for out-of-line calls we are using a small trampoline that
       // pops off the appendix argument and jumps to the target (see gen_special_dispatch in SharedRuntime).
       //
       // Since normal compiled-to-compiled calls are not able to handle such a thing we MUST generate an adapter
       // in this case.  If we can't generate one and use it we can not execute the out-of-line method handle calls.
       AdapterHandlerLibrary::create_native_wrapper(method);

SystemDictionary::find_method_handle_intrinsic() calls CompileBroker::compile_method() directly.

Thanks,
Vladimir

>
> igor
>
> On Sep 4, 2014, at 9:41 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> Looks good.
>>
>> compiledIC.cpp: compute_entry() should not be called when compilation is disabled (-Xint) UseCompiler=false. It should be called only from compiled code.
>> On other hand UseCompiler could be set to 'false' when codecache is full. So I am not sure that you should relax assert by checking !UseCompiler.
>> Or explain why you need it.
>>
>> Otherwise it is good. Thank you for finding the cause!
>>
>> Thanks,
>> Vladimir
>>
>> On 9/4/14 9:24 PM, Igor Veresov wrote:
>>> The main cause of this failure is that class redefinition operation may make all nmethods not entrant, including compiled MH intrinsics. After that ICs referencing those get relinked to c2i adapters that are going to call interpreter versions of MH intrinsics that, in turn, may all compiled methods, converting the same frame with i2c. And since c2i is not composable with i2c the problems ensue.
>>>
>>> The fix is to prevent compiled MH intrinsics from becoming not entrant. I also added a bunch of asserts that watch the invariant that a MH intrinsic should not exist without its compiled version (exception when running in pure interpreter) and compiledICs should not link with their c2i entries.
>>>
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8056154/webrev.00/
>>>
>>> Thanks,
>>> igor
>>>
>