RFR: 8026789 Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection
Staffan Larsen
staffan.larsen at oracle.com
Sat Oct 19 10:42:17 PDT 2013
On 18 okt 2013, at 18:36, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
> > 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.
Yeah, it's a bit of a mixup here...
> 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 work is being done in the background by the Agent class, the App class just waits until the Agent is done.
> The 'Kb' uses in the test should be 'KB'; 'Kb' is kilo-bits.
I'll fix that.
> 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.
I wish there was a way to use the same syntax as the jcmd command line when using a JMX bean, though.
Thanks,
/Staffan
>
> 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
>>
>
More information about the serviceability-dev
mailing list