Thanks for the reviews Serguei and Vladimir. Unless I hear objections in the next 24 hours, I'll push this webrev.
-Doug > On 3 Oct 2018, at 03:14, serguei.spit...@oracle.com wrote: > > Hi Doug, > > The JVMTI related part looks good to me. > Thank you for fixing it! > > Thanks, > Serguei > > On 10/2/18 1:11 AM, Doug Simon wrote: >> It would be great to get some input from the non-compilers teams on this RFR. >> >> -Doug >> >>> On 28 Sep 2018, at 19:51, Vladimir Kozlov <vladimir.koz...@oracle.com> >>> wrote: >>> >>> To let you know, me and Tom R. did review these changes and agreed that it >>> is the least intrusive changes for Hotspot shared code. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: >>>> Adding serviceability-dev@... since this is JVM/TI... >>>> Dan >>>> On 9/25/18 10:48 AM, Doug Simon wrote: >>>>> A major design point of Graal is to treat allocations as non-side >>>>> effecting to give more freedom to the optimizer by reducing the number of >>>>> distinct FrameStates that need to be managed. When failing an allocation, >>>>> Graal will deoptimize to the last side effecting instruction before the >>>>> allocation. This mean the VM code for heap allocation will potentially be >>>>> executed twice, once from Graal compiled code and then again in the >>>>> interpreter. While this is perfectly fine according to the JVM >>>>> specification, it can cause confusing behavior for JVMTI based tools. >>>>> They will receive 2 ResourceExhausted events for a single allocation. >>>>> Furthermore, the first ResourceExhausted event (on the Graal allocation >>>>> slow path) might denote a bytecode instruction that performs no >>>>> allocation, making it hard to debug the memory failure. >>>>> >>>>> The proposed solution is to add an extra set of JVMCI VM runtime calls >>>>> for allocation. These entry points will attempt the allocation and upon >>>>> failure, >>>>> skip side-effects such as posting JVMTI events or handling >>>>> -XX:OnOutOfMemoryError. The compiled code using these entry points is >>>>> expected deoptmize on null. >>>>> >>>>> The path from these new entry points to where allocation can fail goes >>>>> through quite a bit of VM code. One could modify all these paths by: >>>>> * Returning null instead of throwing an exception on failure. >>>>> * Adding a `bool null_on_fail` argument to all relevant methods. >>>>> * Adding extra null checking where necessary after each call to these >>>>> methods when `null_on_fail == true`. >>>>> This represents a significant number of changes. >>>>> >>>>> Instead, the proposed solution introduces a new _in_retryable_allocation >>>>> thread-local. This way, only the entry points and allocation routines >>>>> that raise an exception need to be modified. Failure is communicated back >>>>> to the new entry points by throwing a special pre-allocated OOME object >>>>> (i.e., Universe::out_of_memory_error_retry()) which must not propagate >>>>> back to Java code. Use of this object is not strictly necessary; it is >>>>> introduced to highlight/document the special allocation mode. >>>>> >>>>> The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. >>>>> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >>>>> >>>>> -Doug >
