Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154525 - "Too many root sets" when using a lot of compiled plugins
Summary: "Too many root sets" when using a lot of compiled plugins
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: eclipse-bugs
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-12 14:38 UTC by Luca Barbieri
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version: fc6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-08 23:44:58 UTC

Attachments (Terms of Use)

Description Luca Barbieri 2005-04-12 14:38:55 UTC
Description of problem:
Eclipse crashes with the message "Too many root sets" from Boehm GC in libgcj.
Hundreds of precompiled plugins are loaded, which seems the most likely cause.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install a lot of plugins (meaning /usr/share/eclipse/plugins has 100-1000
2. Compile all them with gcj
3. Run Eclipse and use it
Actual results:
At unpredictable times, Eclipse crashes with the "Too many root sets".

Expected results:
It works.

Candidate solution:
Simply raising the MAX_ROOT_SETS constant should fix this; having a dynamically
sized table would be even better.

Comment 1 Ben Konrath 2005-04-12 22:35:13 UTC
So this is a gcj problem, right?

Comment 2 Luca Barbieri 2005-04-18 18:24:40 UTC
If I'm correct, it is a gcj hard-coded limit that is configured to an inadequate
value for performing certain tasks with Eclipse.

Furthermore, I have noticed that exporting plugins with the PDE seems to trigger
this often.

Having non-precompiled plugins may also trigger this.

Comment 3 Andrew Haley 2005-04-20 15:25:53 UTC
Is this a real problem?  That is, are people going to encounter this in real use?

Comment 4 Luca Barbieri 2005-04-20 15:33:15 UTC
Well, I did, and it seems others could too, and that other complex Java
applications could hit this.

Furthermore the fix should be easy and only increase memory consumption in a
probably insignificant amount relative to memory used by bytecode and compiled code.

Comment 5 Andrew Haley 2005-04-20 15:36:45 UTC
Okay, I just wanted to clarify this wasn't some weird test case.

Do I take it that every plugin is a separate jar file, and compiled to a
separate shared library?

Comment 6 Luca Barbieri 2005-04-20 15:50:15 UTC
Plugins are installed in the usual Eclipse ways, and then a script that compiles
all changed plugins (and all jars in /usr/share/java and similar) is run.

The script compiles like nativify and the Eclipse build scripts.

Some plugins and jars are not compiled due to failures or not having run the
compile script after an upgrade.

The lineup of plugins is similar to the Yoxos Developer edition (i.e. includes
almost everything).

The bug seems to be triggered when starting activities that requires new
plugins/classes to be loaded (which is consistent with my interpretation of it).

Comment 7 Andrew Haley 2005-04-20 15:56:50 UTC
How many such plugins are there?

Comment 8 Andrew Overholt 2005-04-20 16:02:37 UTC
FWIW, I've never run into this problem.

Comment 9 Luca Barbieri 2005-04-20 16:03:18 UTC
Right now $(ls -1|wc -l) in eclipse/plugins returns 479 while $(find . -iname
'*.jar' -print|wc -l) returns 711.

Comment 10 Andrew Overholt 2005-04-28 19:12:10 UTC
I'm going to move this to gcj.

Comment 11 Tom Tromey 2007-03-08 23:44:58 UTC
I'm closing this.  I believe we fixed this in FC6.
Please reopen or comment if you disagree.  Thanks.

Note You need to log in before you can comment on or make changes to this bug.