RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified
albert.noll at oracle.com
Thu Oct 24 07:39:09 PDT 2013
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.
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.
>>>> 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
>>>> 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
>>>> 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,
>>>> P.S.: If anyone has an idea of where the problem could be, please
>>>> let me know!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev