JDK-6307570 : jmap performance and robustness improvement
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-08-08
  • Updated: 2010-08-24
  • Resolved: 2005-08-17
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.

To download the current JDK release, click here.
Other JDK 6
1.4.2_12Fixed 6 b48Fixed
Related Reports
Relates :  
Description
jmap heap dump facility should work at reasonable speed for large heap apps and core dumps.

Comments
SUGGESTED FIX Initial version developed against 1.4.2/sa_baseline: http://bongo.india/debugging/sa/jmapdump-perf-robust/webrev/ 1.5.0/sa_baseline webrev is: http://bongo.india/debugging/sa/jmapdump-perf-robust/1.5.0/webrev 1.6.0 webrev is: http://bongo.india/debugging/sa/6307570/webrev/ Also, refer to attachment "webrev.tar"
2005-08-10

EVALUATION 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.
2005-08-10