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