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

[Albert Noll]

John, Christian,

thanks for providing background information to this bug. This certainly 
helps me in understanding this issue better.
I will file a bug to further work on this issue.

Best,
Albert

On 23.10.2013 19:41, Christian Thalinger wrote:
>
> On Oct 23, 2013, at 10:25 AM, John Rose <john.r.rose at oracle.com 
> <mailto:john.r.rose at oracle.com>> wrote:
>
>> On Oct 22, 2013, at 4:25 PM, Christian Thalinger 
>> <christian.thalinger at oracle.com 
>> <mailto:christian.thalinger at oracle.com>> wrote:
>>
>>>
>>> On Oct 22, 2013, at 7:23 AM, Albert Noll <albert.noll at oracle.com 
>>> <mailto: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/ 
>>>> <http://cr.openjdk.java.net/%7Eanoll/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.
>
> That is some interesting bit of history and finally gives an answer to 
> my question why the I2C/C2I adapters are eagerly generated.  The 
> reason why I stumbled across this a couple weeks ago is I wanted to 
> see if we can generate some (all?) of our adapters from snippet type 
> code and not have handwritten assembler code for them.
>
>>
>> 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/20131024/42d5222f/attachment.html