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

[Vladimir Kozlov]

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.
>