RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified

[John Rose]

On Oct 22, 2013, at 4:25 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Oct 22, 2013, at 7:23 AM, Albert Noll <albert.noll at oracle.com> wrote:
> 
>> Hi all,
>> 
>> I worked on this bug for some time but so far I was not able to determine its root cause.
>> However, I have found a work around that hides the problem. Since it is important 
>> for the embedded version of hotspot to work with small code cache sizes + nashorn,
>> I would suggest to apply this workaround, and file another bug that investigates the problem
>> (e.g., a P4) that we can defer.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8026407
>> webrev: http://cr.openjdk.java.net/~anoll/8026407/webrev.00/
>> 
>> problem: If we do not create native wrapper for method handle intrinsics, we get
>>                segfaults in compiled code. Also, if -XX:VerifyAdapterCalls is enabled, we
>>                get: 
>> 
>>                assert(false) failed: DEBUG MESSAGE: i2c adapter must return to an interpreter frame
>> 
>>                The bug seems to be specific to method handle intrinsics. I assume that we either call
>>                the wrong entry point to a compiled method, or there is a bug somewhere in the generated
>>                adapters. Method handle intrinsics are treated specifically in various parts of the code and 
>>                I do not yet really understand everything.
> 
> I can tell you why (as could John):  in order 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.
> 

Thanks, Chris; that's correct.

Albert, I think you are seeing edge cases (common enough when memory is tight) where compiled code A gets successfully compiled but a stub B that it needs fails to compile.

If this is so, the order of compilation needs to change somehow so that B precedes A, or else A needs to ensure that B compiles before A needs it.

An analogous case is the i2c/c2i adapters for all methods.  There was a time (IIRC) that they were generated more lazily, but we had to make them eager, since we could get the same failure pattern: A compiles but B doesn't, where B is the i2c or c2i adapter.

A third option, which I would prefer if it were feasible, would be to make the compiled paths for the method handle stubs always inlined into the compiled code.  But this is probably difficult, because method handles can point to method handle methods (and do pretty often!), so that it is not always possible for the compiler to know that a call will need to go through a stub's compiled entry point.  There are ways around this also, but it's tricky.

It seems likely to me that there is some kind of economical way to make sure that the stubs (B) are always created before their users (A) get compiled.

Albert, thank you for dissecting this, and so many other gnarly code storage issues.

— John


>> solution: As mentioned above, the solution is a workaround and does not solve the real problem.
>>               Nevertheless it improves stability of hotspot and the impact of the proposed changes are 
>>               marginal. 
>> 
>> testing: Running nashorn with small code cache size (3m) on PPC and x86
>> 
>> There will be a separate mail for closed part changes.
>> 
>> Many thanks in advance,
>> Albert
>> 
>> P.S.: If anyone has an idea of where the problem could be, please let me know!
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131023/58275fa5/attachment.html