RE: [platform-core-dev] Re: Large-scale issues summary

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

" (such as sharing of Strings),
" That part of your answer seems like a bad idea... We will soon be
asked to provide a String caching mechanism to palliate the fact that some
VMs do not GC interned strings (Philippe already asked) :-)

PaScaL

John Arthorne/Ottawa/IBM@IBMCA
Sent by: platform-core-dev-admin@xxxxxxxxxxx

12/01/2004 10:40 AM

Please respond to
platform-core-dev

To	platform-core-dev@xxxxxxxxxxx
cc
Subject	RE: [platform-core-dev] Re: Large-scale issues summary

I guess the document doesn't make it clear, but this was really an exercise
in looking at the "large-scale development" theme from the platform
perspective (i.e., not JDT or PDE).  Many of the very large scale
development issues are also found in C/C++ development tools, so we are
looking for platform improvements that all varieties of Eclipse-based IDEs
can gain from. I am aware that a large amount of the memory usage in the
Eclipse Java IDE comes from JDT plug-ins, and I am sure the JDT teams are
looking at that.  If there are facilities the platform can provide
to help the JDT components reduce their memory footprints (such as sharing
of Strings), we will also look into that.  If you haven't already
done so, I suggest sending your profiling results to the JDT team, either
through a bug report or on a JDT mailing list.

"Ed Burnette" <Ed.Burnette@xxxxxxx>
Sent by: platform-core-dev-admin@xxxxxxxxxxx

01/12/2004 12:36 AM

Please respond to
platform-core-dev

To	<platform-core-dev@xxxxxxxxxxx>
cc
Subject	RE: [platform-core-dev] Re: Large-scale issues summary

John,
These look good but I do have one observation about memory footprint. I've
run Eclipse through the YourKit profiler a number of times to try and understand
what's slowing it down, expecially when you come back to a minimized (and
paged out) instance under Windows. Most of the slowness could be traced
to the IDE's memory footprint, which is typically between 200-300M for
me (I had to use -Xmx256m or higher with JDK1.4.2 to avoid excessive GC
or out of memory errors).

I loaded a workspace which, among other things, had most of the SDK plug-ins
binary-imported and looked at where the memory was going with the profiler.
Most of the memory was used by JDT, not by the platform. For example in
one test, platform-core and platform-ui accounted for roughly 50M of heap
allocations and JDT accounted for almost all the rest (150M+). Most of
the JDT memory was for Java Model objects (JavaElements and whatnot being
stored in some kind of cache).

I did these tests on Windows with Sun JDK1.4.2_something and Eclipse 3.0
so things may have improved  since then, but I still think that trying
to address the IDE's memory footprint by working hard to reduce platform-core's
memory will have only a limited effect if platform-core is nowhere near
the biggest memory user.

BTW, you mention string interning; the tool didn't provide good support
for investigating this but from what I could tell the only area that had
significant problems with duplicate strings was in the ui.commands area
(key definition names, etc.). I believe this is being significantly redone
in 3.1 anyway.
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev