|
Replies:
1
-
Last Post:
May 21, 2008 1:54 PM
by: linuxhippy
|
|
|
|
|
|
|
RMI and garbage collection.
Posted:
May 20, 2008 1:50 PM
|
|
|
|
|
Regarding the server's jvm option: *|sun.rmi.dgc.server.gcInterval...
|*Currently the appserver sets this up to run a full GC every hour.
Documents state that RMI needs to force a GC to ensure remote objects
are unexported.
Why it is bad that the server doesn't know if a remote client has
dropped its reference to the server's exported remote objects?
(This is the stated reason for RMI forcing GCs.)
Is it that the remote jvm can't clean up its own objects in its JVM if
the server is still hanging on to it?
It seems the server, if left to its own devices, (ie no forced GCs) will
clean up whatever objects are unreferenceable in its own time, whether
RMI related or not.
Thanks,
Russ
[att1.html]
|
|
|
|
|
|
|
Re: RMI and garbage collection.
Posted:
May 21, 2008 1:52 PM
in response to: Russ Petruzzelli
|
|
|
Exactly, the client needs to know which objects the server still references, to be able to clear local references to them. Only if those hard references are cleard, the client-gc is able to free the heap occupied.
I've written a rmi-like framework for swing components (its especially tuned for swing and not based on RMI): http://juibrowser.sf.net
It also uses distributed GC, but the problem is even more critical because the server stores only lightweight half-objects, whereas on the client the couterparts are real swing-objects which often weight a few kB. So the server could create millions of UButtons, but the client is OOM after a few hundred thousands.
For such enviroments I would use CMS collector if pauses are critical, and a small nurse/eden space.
This will guarantee frequent GCs, but also impact throughtput negativly.
lg Clemens
|
|
|
|
|
java.net RSS
