Community
Participate
Working Groups
Build: RC2 VM: Sun JDK 1.4.1_01 or _02 (didn't happen with IBM JRE 1.3.1_sr2) Changing the default JRE (triggers a full-build) while a class tree appears on the Hierarchy view causes a OutOfMemoryError. Steps to reproduce: 1 - in a new workspace, import all plug-ins as binary projects 2 - open IResourceChangeListener in the Hierarchy view 3 - open Java->installed JREs preference page, add a second JRE (if you have only one), and make it the default one (or just select a different configured JRE to be default). 4 - Confirming the changes will show a dialog: "The JRE settings have changed. A full build will be required...". Say "yes", you want a full build. 5 - the process will take minutes (what is weird, because we only have binary projects), and will finish with an error: "Creating hierarchy failed. Check log for details". I will add the log (1.2Mb of text, containing lots of deeeeep stack traces).
Created attachment 4012 [details] log file
This one needs investigation. Moving to JDT-Core but we will also look at it here.
What are your settings for the heap size? Do you use -vmargs -X256M or another value on your command line?
Yeap, -Xmx256m did the trick. The default maximum stack size for Sun JDK 1.4.1 is 64 MB (don't know what is the default for IBM's JREs). Anyway, are the deep recursive calls (> 50 levels) in TypeHierarchyViewPart's runnable what you expect to happen in such scenario (the bug does not happen if the Hierarchy does not have to refreshed)? If so, feel free to close it as user's fault.
Erich, any comment on the deep recursive call on TypeHierarchyViewPart?
Cannot explain the stack trace - this needs further investigation. Adopting bug.
The reason for the queued up asych execs is that the launcher calls the JRE initializers for each project, but does not batch this. Each call to the initializer results in a delta, and each delta result is a asynch exec posted by the type hierarchy. When the JRE page invokes the build in the forked mode, the async execs are executed in the middle of the build. Fixed in the type hierachy by adding a new flag that prevents the posting of a runnable if there is still an update request pending. Filed bug 34919 against debug to batch the calls to the initializers. > 20030313 Erich, can you review? The modfied file is TypeHierarchyViewPart.java The same release also fixes bug 34068 (return statement after isVisible check)
reviewed
