Still good.
On 30/01/2014 11:52 PM, Markus Gronlund wrote:
Thanks guys.
Yes, the reason I added the return in 37 is to avoid anyone adding anything
after the else clause moving forward. However, as Dmitry pointed out, an
inversion of the version check will make this clearer - thanks.
Given the death of hsx the version check seems removable altogether ;-)
Cheers,
David
In addition, just realized I hadn't pulled in the latest changes for the last
webrev (for the diff), there were actually recent updates to this file as of:
changeset: 9197:902aa2b3265c
user: simonis
date: Mon Jan 20 17:16:05 2014 +0100
summary: 8031581: PPC64: Addons and fixes for AIX to pass the jdk
regression tests
So here's an updated webrev for your convenience:
http://cr.openjdk.java.net/~mgronlun/8032518/webrev02/
Dmitry:
With the pull, the locations of "free, throw, return" reduces to only two so I
don't think refactoring here will add much. Thanks for pointing it out though.
Cheers
Markus
-----Original Message-----
From: David Holmes
Sent: den 30 januari 2014 13:06
To: Markus Gronlund; serviceability-dev@openjdk.java.net
serviceability-dev@openjdk.java.net; hotspot-runtime-dev
Subject: Re: RFR(XXS): 8032518: fatal error has been detected by the Java
Runtime Environment (access violation)
This is good to me. The return at line 37 was unnecessary but it does help
reinforce the pattern that you must return after JNU_ThrowXXX
David
On 30/01/2014 9:11 PM, Markus Gronlund wrote:
Greetings,
Kindly asking for reviews for this very small fix:
Bug: https://bugs.openjdk.java.net/browse/JDK-8032518
Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/
Background:
Still a bit puzzled about the manifestations of the crashes when
inspecting the .mdmp files, which seems to be dereferencing a (debug)
ResourceObj allocation[0] cookie address (~allocation address) at
point of crashing. In addition, if the issue is an effect of not
handling OOM correctly, I would expect to see a _pending_exception off
the problematic thread, but there seems to be none. Also unknown why
this seems to occur more on Windows x64 than any other platform.
Testing:
I have iterated the testcase nsk/stress/jck60/jck60014 locally -
without suggested fixes I get about 10 crashes in about 300 runs. With
fixes I am yet to see any crashes, currently ~600 iterations.
I suggest to putback this first (since it should be fixed anyhow), to
see the effect, before any more time is spent on tracing this down.
Thanks
Markus
