JDK-6307570 : jmap performance and robustness improvement
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
jmap heap dump facility should work at reasonable speed for large heap apps and core dumps.
Initial version developed against 1.4.2/sa_baseline:
1.5.0/sa_baseline webrev is:
1.6.0 webrev is:
Also, refer to attachment "webrev.tar"
The following improvements can be done:
# cache InstanceKlass Field list and instance size and re-use it (instead of creating this for every Instance).
# rewrite writePrimitiveArray - avoiding field walking by iterateFields (and Field object creations). primitive type sizes and array base offsets are read up-front and cached.
# rewrite writeObjectArray - avoiding ObjectHeap.newOop for elements. -- all we want are addresses of elements and so reading OopHandles
# Avoid calls to Symbol.asString calls for signature Symbols. Just looking at first char using getByteAt(0) instead.
# While writing object/array fields of Instance objects, avoid ObjectHeap.newOop call and directly reading OopHandles.
# avoid temp. file creation and file copy (use FileChannel and seek)
# avoid second time walking of heap for Symbol (use explicit symbol table walking - using SymbolTable.symbolsDo)
# explicit SystemDictionary walking to dump class (avoid classes list maintenance)
# add dummy allocation site of zero frames - so that HAT can be run without -stack false option (renamed INVALID_STACK_TRACE_ID to DUMMY_STACK_TRACE_ID).
Please refer to "suggested fix" as well.