RFR(S): 8146424: runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap
Christian Thalinger
christian.thalinger at oracle.com
Fri Jan 22 22:41:06 UTC 2016
Looks good.
> On Jan 22, 2016, at 12:23 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>
> I added a regression test and generated a new webrev http://cr.openjdk.java.net/~never/8146424.01/webrev/index.html <http://cr.openjdk.java.net/~never/8146424.01/webrev/index.html>
>
> tom
>
>> On Jan 22, 2016, at 11:17 AM, Tom Rodriguez <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>> wrote:
>>
>> http://cr.openjdk.java.net/~never/8146424/webrev/index.html <http://cr.openjdk.java.net/~never/8146424/webrev/index.html>
>>
>> JVMCI needs to provide access to Interpreter::size_activation so that JVMCI compilers can properly bang stacks based on their deoptimization requires. This simply adds a new entry point the compiler can use to compute the required size. It also exposes HotSpotVMConfig.vm_page_size instead of requiring the compiler to rely on Unsafe.pageSize which has unspecified relationship to that value.
>>
>> Tested with Graal and the jtreg stack banging tests. I was unable to reproduce the exact reported failure locally though I confirmed that more stack banging was being done in the required places.
>>
>> tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160122/ca14a936/attachment.html>
More information about the hotspot-compiler-dev
mailing list