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

[Christian Thalinger]

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.

> 
> 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/20131022/655a36a0/attachment.html