RFR(S) 8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap

[Igor Veresov]

> On Jun 20, 2018, at 3:43 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> On 6/20/18 3:22 PM, Igor Veresov wrote:
>>> On Jun 20, 2018, at 3:20 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>> Why Graal is affected even when LOHP is not used?
>> LOHP is dynamically turned on by JVMTI.
> 
> Okay. In other world we can't use fast TLAB refill because JVMTI can switch on LOHP at any time. Got it.
> 

Well, unless we want to add an additional dynamic check of the LOHP state. That’s also a possible solution if we want to keep the fast TLAB refill.

> I still did not get why GC tests which do not use LOHP still fail with Graal. And how these changes fix it?

Because, as Stefan noted in the bug, when Graal does fast TLAB refill it does so without setting the new _allocation_end field.
The changes fix it by avoiding manually allocating TLABs in the stub (during fast TLAB refill) and calling the runtime instead.

igor  

> 
> Thanks,
> Vladimir
> 
>>> 
>>> I don't see changes which mapped new TLAB fields added by Low-Overhead Heap Profiling.
>>> 
>>> I don't see your answers to Stefan's comment in bug report about Graal's code which is not fixed for _allocation_end.
>>> 
>>> Does Graal still use fast TLAB refill as default mode?
>> You cannot use TLAB refill with LOHP at all.
>>> 
>>> FastTLABRefill was deprecated by 8194084: "Obsolete FastTLABRefill and remove the related code":
>>> 
>>> http://hg.openjdk.java.net/jdk/jdk/rev/9010e596f391
>>> 
>>> Should we remove it from Graal too?
>>> 
>> Not for JDKs <11.
>> igor
>>> Thanks,
>>> Vladimir
>>> 
>>> On 6/20/18 2:47 PM, Igor Veresov wrote:
>>>> Low-Overhead Heap Profiling is not compatible with fast TLAB refill. It needs to be disabled.
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8205105/webrev/
>>>> Thanks,
>>>> igor