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

Roland Westrelin roland.westrelin at oracle.com
Wed Nov 26 09:52:55 UTC 2014


Here is a new webrev that should address the comments:

http://cr.openjdk.java.net/~roland/6898462/webrev.01/

Popping all frames made the change much simpler.

Roland.

> On Nov 20, 2014, at 10:48 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> Some more thoughts on testing this fix:
> 
> Existing tests cover the intentions of this fix, since the fix responds to existing test crashes.  This fix should upgrade their behavior to a more graceful OOME instead of a crash.
> 
> A regression test we need for this is one which exercises the new code.  If we are sure existing stress tests do this already, and if we are confident that we will recognize regressions from this code, I think that's enough to get by.
> 
> The small reproducer unit test (TestDeoptOOM.java) should reliably exercise OOME and reallocating deopts at the same time, and nothing else; it should expect an OOME and not crash.  Its value is disagnose-ability, since it exercises the new code paths.  It doesn't really increase coverage.
> 
> Does it need to be tested nightly or on multiple platforms?  No, I think not.
> 
> — John
> 
> On Nov 20, 2014, at 1:02 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> Most likely we still fail existing tests since OOM behavior is different (delayed) with EA and this fix. GCBasher test we can fix (disable EA or change catch code) and I hope Kitchensink does not care where OOM is thrown.
>> 
>> I would say to not spend time on existing tests failures which are hard to reproduce. Fix current bug, closed is as resolved and if some tests fail after that we create a new bug and see how we can fix them.
>> 
>> Thanks,
>> 
>> 
>> On 11/20/14 11:57 AM, Roland Westrelin wrote:
>>>> So, I concur that popping all the frames is the best thing to do for now.
>>> 
>>> Thanks and thanks for the other comments. I’ll send an updated webrev.
>>> 
>>> The other question is how much testing we think we need for this. Is it sufficient to check that it doesn’t break normal execution and that the regression test I’m adding covers all scenarios we can think of? Or do we want to reproduce failures that were reported on existing tests? The problem with doing that is that they are all hard to reproduce and it seems it would be very time consuming. Also I’m not sure what guarantees we would get out of it: from one run to another depending how much inlining a compilation does we could pop more or less frames in case of an OOM so the effect on the test case could vary. That this change doesn’t break a test case won’t mean it doesn’t break it on another run. What do you think?
>>> 
>>> Roland.
>>> 
> 



More information about the hotspot-compiler-dev mailing list