Emil expressed a concern that the SIP Communicator process used a
large amount of memory and this usage didn't seem justified. As an
example he pointed to Spark which showed much lower process memory
The following are the start of observations and work on the subject.
By looking at Spark, I figured that it uses the -client Java launcher
argument on Linux. It turned out that Java 1.5 has introduced
automatic server-class machine detection which means that in the
absence of explicit request on the side of the user the launcher will
choose between -client and -server on startup. On my Ubuntu running on
MacBook, Sun JRE 6 automatically chooses -server and thus causes the
SIP Communicator process to start up with a large amount of memory.
Explicitly providing the -client command line argument in the "run"
target of our build.xml resulted in cutting down the startup process
memory roughly in half.
While this Linux experience sounds very encouraging, the situation
doesn't seem to be the same on Mac OS X Leopard and its default Java
configuration because it uses -client by default, yet the process
memory usage appears to be higher than desired. The bummer is that I
don't see anything specific to memory in Spark on Mac OS X.
Snow Leopard is a tad different I think. It has switched to Java 6,
defaults to starting the launcher in 64-bit mode (on the command line
at least). Which means that "ant run" will attempt to start 64-bit SIP
Communicator which itself translates to the VM being in -server mode
and this leads to relatively high startup process memory again. This
can be remedied by specifying the -d32 command line argument in the
"run" target of our build.xml, -client will not do because Mac OS X
still defaults to running the process in 64-bit mode and -client is
ignored. Fortunately, "SIP Communicator.app" installed from .dmg
starts in 32-bit and -client mode so it has lower memory use. On my
Snow Leopard, the -client VM cuts down the process memory usage of SIP
Communicator with no accounts by roughly 40%. So now, given no
accounts, Spark starts with 40MB and SIP Communicator with 70MB on
I'm currently looking into the differences between Spark and SIP
Communicator which cause the latter to start with as nearly twice as
much memory as the former. In line with the Octopus' "I've got eight
of everything" in the movie "The Spirit", a possible explanation is
that SIP Communicator (roughly) loads twice as many classes, opens
twice as many files, starts twice as many threads. Indeed, it seems to
me that when creating a new account, the memory bumps up more when
creating a new type of account (i.e. when more classes are loaded) in
comparison to creating a second account from a type I already have an
Following this line of thinking, I removed branding.jar on Mac OS X
Snow Leopard and on Ubuntu. The reasoning for doing it is primarily
that the splashscreen has always showed as consuming a lot of memory
because of its image and HTML (which requires loading a lot of classes
and has slow rendering) and it holds onto that memory while nearly all
of the other bundles are starting i.e. when the application is at its
peak of memory needs. This removal spares roughly 5MB of process
memory on both operating systems for me. Additionally, it accounts for
faster startup. I plan to look into the branding plugin a bit more and
maybe switch its utilization through a configuration property.
Another champion in class loading is the media bundle which spawns a
thread to detect the capture devices. The possible problem that it may
deserve looking into is taking control of starting such threads so
that these threads don't all execute and require memory at the same
time and at the time that the rest of the application is loading and
is itself requesting memory.