> 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