Community
Participate
Working Groups
My results with a fresh workspace were: 3.6 - Heap memory: 12 MB e4 - Heap memory: 24 MB (= 12 MB in addition) A memory snapshot comparison shows that e4 has a lot more strings on the heap (difference accounts for ~6.5 MB). 3.6 - 39.107 strings e4 - 89.136 strings (= 50.029 strings in addition) A comparison between two memory snapshots with allocation information shows that the strings are created where one would not expect them to be created. See attached screenshots for details.
Created attachment 173666 [details] String allocations in 3.6
Created attachment 173667 [details] String allocations in e4
I think I was looking in the wrong place. The different results seem to stem from a different order in which the bundles get activated. I will do some more investigation.
What I found isn't a bug, just some strange behavior. The difference between 3.6 and e4 was that in e4 all ClasspathManifest objects had their Manifest loaded (see ClasspathManifest.getManifest(...)), while in 3.6 this was not the case. For 3.6 I had started Eclipse with the plugins from the running platform. After I imported them into my workspace as binary plugins with linked contents, the Manifest objects were loaded in 3.6 as well, and the heap size was increased as in e4. Remaining question: Are the Manifest objects necessary at all? Eclipse doesn't really seem to need them. Are they used for enforcing the access rules? (Sorry for generating some noise in the bug list.)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This is a mass change to close all e4 bugs marked with "stalebug" whiteboard. If this bug is still valid, please reopen and remove the "stalebug" keyword.
