Community
Participate
Working Groups
Build: I20040607 Steps: 1) Checkout org.eclipse.core.runtime from dev.eclipse.org 2) Close all perspectives 3) Open Resource perspective 4) Close all views 5) Customize perspective to add "Open Type" command 6) Ctrl+Shift+T 7) Type "Path" 8) Hit ok 9) Wait for CPU to settle down, then close editor 10) Ctrl+Shift+T 11) Type "Path" -> Start Heap profiler 12) Click ok -> After activity stops, stop profiler In this test, DefaultCommentTracker creates: - 5996 instances of DefaultCommentTracker - 5996 instances of ArrayList - 6012 instances of Object[] All of this garbage is created by the visitor itself. The code is implemented using a recursive method (doExtraRangesForChildren). On each recursive step, it creates a visitor to visit and collect the children of each node. Couldn't this be implemented by a single AST visitor, rather than a recursive method that creates a new visitor for each node? Note: The entire reconcile seems to happen TWICE in this scenario. I will attach an allocation backtrace that shows how this happens.
Created attachment 11677 [details] Reverse allocation backtrace showing origin of two separate reconciles
Must fix.
Fixed. Rewrite visitor of DefaultCommentMapper to avoid unnecessary initialization. Also optimize trailing comments to avoid scan after node end position when node has same end position than its parent... Also avoid unnecessary instanciation of DefaultCommentMapper while converting javadoc for dom ast hierarchy [jdt-core-internal] Changes done in DefaultCommentMapper + ASTConverter No test cases added: existing massive test DefaultCommentMapperTests run on all eclipse java files validated that change has no impact on heuristic result... I will quantify more precisely memory + GC + time gain with this new implementation and dump results in this bug tomorrow...
New visitor is only doing one traversal, with a map to record pending child. It is relying on deferring the computation of extended source range until it traverses a sibling of a node (recorded as pending until traversing a subsequent node with same parent, then parent processes last pending child when doing #endVisit). We should investigate post 3.0 using the same approach we took for source ends (-1 if same as parent end), to optimize source starts to rely on parent extended source range.
Using YourKit Java Profiler I got following memory result: Before fix: GCed Objects GCed Size (bytes) DefaultCommentMapper 11250 359,056 DefaultCommentMapper$ChildrenCollector 6004 241,056 After fix: GCed Objects GCed Size (bytes) DefaultCommentMapper 3713 101,424 DefaultCommentMapper$CommentMapperVisitor 1494 56,920 Which represents a down size of 73.6% for garbaged allocated memory while opening Path.java file.
Verified for 3.0RC2 I20040611
