It occured to me that perhaps I should consider the memory footprint of Swing rather than its lightweight..
And I have here a paper to help.
System checkpointing using Reflection and Program Analysis If anyone can add anything else I'd be much obliged.
regards
[ June 17, 2003: Message edited by: HS Thomas ]
The Java programming language has gained a significant following due to a
number of reasons, including its clean, object-oriented design and automatic
storage management. It is a very popular choice for server-side applications;
however, on the client side, Java has yet to make significant headway against
more established languages like C and C++.
There are currently two major problems that must be overcome before Java
can become prevalent on the client side. The first is application startup time [5].
Applications using the Swing GUI interface can take on the order of minutes
to start up. This is due to a number of factors, including large amounts of
inecient initialization code in the class libraries and the fact that (in most
virtual machines) the code is recompiled from class files on every execution.
The second major stumbling block in the adoption of Java on the client side
is memory footprint. Even simple GUI applications can regularly consume 20
megabytes or more of memory [8]. What is more, in most systems this memory
is not shared among applications, which means that 20 megabytes per running
instance are consumed. Again, this is due to a number of factors, including the
liberalism of virtual machine garbage collectors in allocating memory and the
dynamic and object-oriented nature of the Java language. Because of dynamic
features such as reflection and dynamic class loading, the system cannot perform
whole-program analysis to eliminate the (as-of-yet) unused fields, methods, and
other runtime data structures.
To attack these problems, we developed a general technique of checkpointing
the state of the system using reflection. Checkpointing is the act of saving the
state of a running system such that it can be recreated later in time. Checkpointing
has many applications, including system recovery, debugging, bootstrapping,
and process migration. We use checkpointing for a dierent purpose. By running
the system up to a certain point and then checkpointing it, we can use the checkpointed
version to avoid startup time costs; in essence, application startup time
becomes bounded only by disk latency. Furthermore, we can perform analysis
during the checkpointing process to optimize the system, reducing the memory
footprint by eliminating unnecessary code, objects, fields, classes, and runtime
data structures.
Using reflection makes our technique very flexible. Because we use reflection,
we can precisely control the checkpointing process, deciding what data to ignore
and what data needs to be reinitialized on virtual machine startup. Furthermore,
the technique is entirely virtual machine and architecture independent;
we actually use this technique to bootstrap the joeq virtual machine across
platforms
[ June 17, 2003: Message edited by: HS Thomas ]