Request for review for JDK-8178507 - co-locate nsk.regression.gc tests
alexander.harlap at oracle.com
Mon Jun 26 20:04:35 UTC 2017
I accommodated your suggestions.
New version of changeset located at
On 6/23/2017 6:18 PM, Leonid Mesnik wrote:
> Basically changes looks good. Below are some comments:
>> On Jun 22, 2017, at 9:16 AM, Alexander Harlap <alexander.harlap at oracle.com> wrote:
>> Please review change for JDK-8178507 <https://bugs.openjdk.java.net/browse/JDK-8178507> - co-locate nsk.regression.gc tests
>> JDK-8178507 <https://bugs.openjdk.java.net/browse/JDK-8178507> is last remaining sub-task ofJDK-8178482 <https://bugs.openjdk.java.net/browse/JDK-8178482> - Co-locate remaining GC tests
>> Proposed change located at http://cr.openjdk.java.net/~aharlap/8178507/webrev.00/
>> Co-located and converted to JTREG tests are:
>> nsk/regression/b4187687 => hotspot/test/gc/TestFullGCALot.java
> The out variable is no used and return code is not checked in method “run”. Wouldn't it simpler just to move println into main and remove method ‘run’ completely?
>> nsk/regression/b4396719 => hotspot/test/gc/TestStackOverflow.java
> The method ‘run’ always returns 0. It would be better to make it void or just remove it. Test never throws any exception. So it make a sense to write in comments that test verifies only that VM doesn’t crash but throw expected Error.
>> nsk/regression/b4668531 => hotspot/test/gc/TestMemoryInitialization.java
> The variable buffer is “read-only”. It make a sense to make variable ‘buffer' public static member of class TestMemoryInitialization. So compiler could not optimize it usage during any optimization like escape analysis.
>> nsk/regression/b6186200 => hotspot/test/gc/cslocker/TestCSLocker.java
> Port looks good. It seems that test doesn’t verify that lock really happened. Could be this improved as a part of this fix or by filing separate RFE?
>> Thank you,
More information about the hotspot-dev