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

[Albert Noll]

Hi Igor,

thanks for looking at the patch.

You are right. If there is not enough free space in the code cache to 
generate the wrapper,
we might crash again. However, it did not show up during the tests. I'll 
file a new bug (P4?) to
further investigate.

Best,
Albert


On 22.10.2013 20:17, Igor Veresov 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 
> <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.
>>
>> 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/6e66d5f2/attachment-0001.html