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

[Vladimir Kozlov]

Albert,

I saw this change is pushed and I am fine with this. But, as Igor said, please file new bug and investigate it when you have time.

Thanks,
Vladimir

> On Oct 22, 2013, at 2:17 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
> What if there's no space to create the wrapper? Do we crash?
> I guess the workaround is ok for now, but please file a new bug to investigate.
> 
> igor 
> 
>> 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.
>> 
>> 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/a61a1e27/attachment.html