> webrev: http://cr.openjdk.java.net/~sla/8026789/webrev.00/

test/ProblemList.txt
    Interesting. The tests are on the list via 8023201, but you're
    tweaking the tests via 8026789. I'm guessing you don't want to
    say (yet) that this fix resolved the 'leak' in 8023201.

test/java/lang/instrument/RedefineBigClass.sh
    No comments.

test/java/lang/instrument/RedefineBigClassApp.java
    line 38: // Do a short warmup before creating the NMT baseline
        I think of 'warmup' as running code rather than sleeping.
        Perhaps:

        // Give the VM some time for initial memory allocs to happen.

     The 'Kb' uses in the test should be 'KB'; 'Kb' is kilo-bits.

test/java/lang/instrument/RetransformBigClass.sh
    No comments.

test/java/lang/instrument/RetransformBigClassApp.java
    line 38: // Do a short warmup before creating the NMT baseline
        Same comment as above.

    The 'Kb' uses in the test should be 'KB'; 'Kb' is kilo-bits.

test/java/lang/instrument/NMTHelper.java
    Nice, very nice.

Thumbs up.

Dan


On 10/17/13 12:30 PM, Staffan Larsen wrote:
The two tests currently use /proc/self/stat to read the virtual memory usage 
for the process. This only works on linux and only gives a single  value to 
analyze. NMT works on all platforms and gives a lot more detail about where the 
memory is consumed.

Without this fix, I can repro JDK-8023201 when stressing the machine heavily, 
but with this fix the test passes. The reason for this is probably that NMT 
uses a more granular measurement of committed memory, and not that the VM 
actually uses less memory. I have retained the memory growth limit of 32MB, but 
if that is a good value or not, I don't know. When stressing the test, I see 
NMT reporting about 1MB in committed memory growth.

I have also removed the tests from ProblemList.txt.

webrev: http://cr.openjdk.java.net/~sla/8026789/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8026789

Thanks,
/Staffan


Reply via email to