Review Request: 8009298 and 8009777 (original) (raw)
Zhengyu Gu zhengyu.gu at oracle.com
Mon Mar 11 11:21:49 PDT 2013
- Previous message: hg: hsx/hotspot-main/hotspot: 4 new changesets
- Next message: Review Request: 8009298 and 8009777
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
8009298: NMT: Special version of class loading/unloading with runThese stresses out NMT <https://jbs.oracle.com/bugs/browse/JDK-8009298> 8009777: NMT: add new NMT dcmd to control auto shutdown option <https://jbs.oracle.com/bugs/browse/JDK-8009777>
The two are related. The change is to add an addition VM diagnostic command-line option "AutoShutdownNMT".
By default, native memory tracking runtime shuts itself down under stress situation, and release memory to allow JVM continue running. But this feature can be undesirable when this is the situation we really want to know what's happening to JVM memory usage, even that means that we need to sacrifice JVM performance.
When AutoShutdownNMT is set to false, NMT will try its best to stay alive by slowing down threads calling memory allocation/de-allocation.
Webrev: http://cr.openjdk.java.net/~zgu/8009298/webrev.00/
Tests: The test case is special version of runThese, it uses 12 threads to load/unloading classes without executing any tests.
Following two memory usage graphs show the different behavior with AutoShutdownNMT on/off.
AutoShutdownNMT = true http://cr.openjdk.java.net/~zgu/8009298/webrev.00/autoShutdown.png The steep drop in memory usage was result of shutting down of native memory tracking.
AutoShutdownNMT = false http://cr.openjdk.java.net/~zgu/8009298/webrev.00/noAutoShutdown.png The steep dig was result of class unloading.
Thanks,
-Zhengyu
- Previous message: hg: hsx/hotspot-main/hotspot: 4 new changesets
- Next message: Review Request: 8009298 and 8009777
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]