Still good. On 30 jan 2014, at 14:52, Markus Gronlund <markus.gronl...@oracle.com> 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. > > 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 >>
