ClassLoaders and object space

Thread view:

Jeremy - 27 Jun 2003 06:30 GMT

Hi,
I'm writing an application which will load dynamically different plug-in
"applets". The memory demands of these applets aren't known, since they
don't exist yet, but some are graphics-related and could gobble up lots of
memory. It was suggested to me that I use a different ClassLoader instance
for each applet as it would then have its own object space - I'm a pretty
good java programmer, but I don't know that much about how the virtual
machine works (it just does) and I'm not familiar with this level of memory
management. Could anyone point me to some good reading on this subject
(maybe a good book on java memory management specifics)? Right now I just
have a single classloader instance which handles all the loading - it works
fine for the stub applets, but I want to look into this more thoroughly.

Thanks,
-Jeremy

Reply to this Message

Markus Knauss - 27 Jun 2003 07:36 GMT

Hi,

have a look in the "Java Virtual Machine Specification" which is
available online or for download from Sun Microsystems.

URLs:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html

For me it worked fine.

Greetings,
Markus

Reply to this Message

Jeremy - 27 Jun 2003 18:45 GMT

Thanks for the link - very useful information, I'm suprised I didn't already
have it.

Thanks!
-Jeremy

> Hi,
>
[quoted text clipped - 8 lines]
> Greetings,
> Markus

Reply to this Message

Chris Uppal - 27 Jun 2003 12:09 GMT

> I'm writing an application which will load dynamically different
> plug-in "applets". The memory demands of these applets aren't known,
> since they don't exist yet, but some are graphics-related and could
> gobble up lots of memory. It was suggested to me that I use a
> different ClassLoader instance for each applet as it would then have
> its own object space.

AFAIK, the only difference that using separate class loaders would make is that
it would allow the applet's classes to be GCed. A class can't be GCed until
it's class loader is also eligible for GC, so using separate class loaders
would stop the applet classes accumulating in your single class loader.

(It'd also protect the applets from each other's name spaces, but that's not a
*memory* issue.)

If the applets are likely to use lots of class-side (static) data -- as a
"global" cache for instance -- or if you are likely to load/unload lots of
different applets over the course of one run of your overall application, then
it could be worthwhile. OTOH if you only have smallish fixed set of long-lived
applets, which are written "responsibly" (i.e. not supplied by outsiders, or by
coders who don't realise how they are going to be used) then it probably
wouldn't make much difference to memory use.

-- chris

Reply to this Message

Jeremy - 27 Jun 2003 18:49 GMT

Thanks, exactly what I was looking for. I think I am going to opt for
separate classloaders because that seems to be the more robust way to go
about it. The app is actually a server application and these plugins are
going to be loaded and unloaded several times a day - if they can't be freed
by the garbage collecter then it's not going to last long!

Thanks again for your help.

-Jeremy

> > I'm writing an application which will load dynamically different
> > plug-in "applets". The memory demands of these applets aren't known,
[quoted text clipped - 20 lines]
>
> -- chris

Reply to this Message

ClassLoaders and object space

Free Magazines