RFC: 6898462: The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Nov 18 23:19:03 UTC 2014


Good :) Really, I almost did not find any serious issues with these changes.

The only question I have: why not pop all interpreter frames 
corresponding to deoptimized compiled frame? You are trying to find the 
top popped frame in vframeArray.cpp. But how we guarantee that frames 
which are not popped are in correct state after deoptimization?

deoptimization.cpp:

I think next assert should be guarantee or fatal:

assert((failed_realloc_from_top != 0) == realloc_failures, "inconsistent 
state");

Add to next comment that inconsistent state of monitors are due to 
failed reallocation of synchronized objects (am I right?):

+     // Unlock all monitors here otherwise the interpreter will see a
+     // mix of locked and unlocked monitors and be confused.

set_removed_monitors() is defined only under ASSERT:

+        array->element(i)->set_removed_monitors();

thread.hpp - fix comment:

+   // If a reallocation of scalar replaced objects fails during 
deoptimization,
+   // we throw OOM and during exception propagation, pop the top
+   // _frames_to_pop_failed_realloc interpreter frames corresponding
+   // to the deoptimized compiler frame.


vframe_hp.cpp

may be:

((ObjectValue *)sv)->value()->is_null()

instead of

((ObjectValue *)sv)->value()() == NULL


TestDeoptOOM.java - @summary is wrong.
Why you exclude OSR? You can exclude main() from compilation instead. 
And we need special OSR subtest to verify that frames are reconstructed 
correctly for OSR compilation. An other case is 2 scalarized allocations 
and one's field references an other.

Thanks,
Vladimir

On 11/18/14 11:29 AM, Roland Westrelin wrote:
> This is the OOM during deoptimization that causes a crash problem.
>
> Here is the change I propose:
>
> http://cr.openjdk.java.net/~roland/6898462/webrev.00/
>
> I haven’t done a lot of testing. I’m looking for feedback.
>
> With that change, the top interpreter frames that reference a failed reallocation are unconditionally popped as the exception is propagated. I record the number of frames to pop in the JavaThread structure and pop the frames in the interpreter runtime code that does the exception propagation.
>
> Roland.
>


More information about the hotspot-compiler-dev mailing list