Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 9362

Summary: Reliable way to crash eclispe
Product: [Eclipse Project] JDT Reporter: Martin Möbius <m.moebius>
Component: UIAssignee: Martin Aeschlimann <martinae>
Status: RESOLVED DUPLICATE QA Contact:
Severity: major    
Priority: P3 CC: philippe_mulet
Version: 2.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows 2000   
Whiteboard:

Description Martin Möbius CLA 2002-02-10 05:02:22 EST
My workspace consists of the most plugins of eclipse, imported by selfhosting 
plugin (all jdt + required ones). 
By accident i choosed in hierarchy view Focus on 'Object'. After a short while 
eclipse disappeared (crashed) without any warning. There isn't any log so i 
can't  provide more details.
As there are quite a lot of classes i think it could be an out of memory 
problem but there isn't any exception thrown, wich i would expect.

Version 20020125
JDK 1.3
Comment 1 John Arthorne CLA 2002-02-11 12:10:16 EST
In Build 20020205, the UI freezes for about two minutes, but it eventually 
returns and displays all types in the view.  Most of this time seems to be taken 
by sorting and displaying the results -- moving to JDTUI for comment.
Comment 2 Martin Möbius CLA 2002-02-11 16:04:16 EST
Just noticed a problem with my computer, perhaps it's a bug with my ram. Will 
test my machine and report again
Comment 3 Martin Möbius CLA 2002-02-11 17:10:22 EST
Exchanged ram.
Think i got an explanation. If i start without -vmargs -Xmx256M it kills 
eclipse, with it all works fine (just too slow).
In addition, if i execute the operation successfully, than close eclipse an 
restart without the -vmargs eclipse crashes too.
Comment 4 Erich Gamma CLA 2002-02-12 03:53:09 EST
Some more observations:
* computing the type hierarchy on Object with all its subtypes is memory 
intense. In my workspace the memory consumption went up by 55 MB (starting with 
115MB). It isn't the UI since I do the operation in the super types view. This 
means only Object will show up as a result. 

* switching the view to the subtypes view is slow again > 2 minutes and the 
memory consumption goes up by another 50 MB. The tree is flat and even though 
we only show the immediate children you end up with a tree with thousands of 
nodes.

Opening a type hierarchy on object is not useful but we should handle it better.
Questions:
Q1) 55 MB for computing the type hierarchy is high. Philippe is there anything 
core can do to reduce the memory consumption?

Q2) switching to the subtypes hierarchy is slow again, does all the time go 
into creating tree items? We should investigate.

Proposals for improving (in addition to reducing the memory footprint):
a) show a progress monitor with the option to cancel. 
b) warn the user before starting the operation that it can take a while
c) don't allow opening a type hierarchy on Object.
Given that opening a type hierarchy on Object isn't useful option c) would be a 
pragmatic but acceptable solution.
Comment 5 Philipe Mulet CLA 2002-02-12 19:26:20 EST
I like better the allowing to cancel approach, since JCL developpers might care 
about Object hierarchies.

Computing the hierarchy for Object is memory intensive, since it is pretty much 
resolving the entire workspace content dynamically. No matter how optimized we 
are, it will still take cycles. We will investigate hierarchy performance when 
doing a performance pass (likely around M5).
Comment 6 Martin Aeschlimann CLA 2002-02-15 05:48:43 EST
I also think that it should be possible to cancel the creation of the hierarchy
-> see bug 9446

*** This bug has been marked as a duplicate of 9446 ***