[java-gnome-hackers] Res: The next stage in memory management

[Vreixo F. L. <met...@ya...>]

Hi all,

I hope to take a further look at this asap, but I'd like to give you some impressions about this issue:


> Now, what most people meant when they talk about "unreliable" is that
> they are not "guaranteed" to be called; a number of circumstances
> [/implementations] just terminate the Java VM process without calling
> the finalizers of every bloody object

In any case, a "kill -9 whatever" will terminate the JVM without any cleanup (either in finalize() 
or by other means) so I doubt "special circumstances" should be handled at all by java-gnome.

>. So if (say) you're holding on to
> database client connections, they won't necessarily get cleared /
> closed / etc. Bad.

That's not necessarily true. When a process finalizes (either normal way or killed) Linux will
free the systems resources it was using. In particular, TCP connections are regularly closed 
(I mean, a TCP FIN packet is sent, however application-level close, if any, is not, as expected).

> The problem is that the full Java garbage collector [and I'm talking
> about OpenJDK HotSpot here] does not ordinarily run until the VM thinks
> it is out of heap. And that isn't going to happen anytime soon on most
> systems. Which means that finalize() isn't get called until *MUCH* later
> than we'd like, and we're holding on to tons of memory (allocated by
> glib) unnecessarily.

I wonder if what we should do is to launch any java-gnome application with specific
GC-related JVM options.

> Telling people just to call System.gc() doesn't really seem to address
> the weakness.

Afaik, in modern JVM System.gc() does nothing.

> Which brings us back to the _other_ purpose of SoftReference,
> WeakReference, and PhantomReferences: taking actions on Java objects as
> they go through the lifecycle, including being able to do cleanup long
> before finalize() gets called by the GC in it's second last phase.

In any case, does not the GC need to be called in order to the JVM detect an object
has changed its reachability? In such case, using another kind of reference would be
useless. Or am I missing something?

> Presumably we want another WeakReference, plus a ReferenceQueue. The
> question is: what will poll the reference queue, and when?

What exactly are you thinking about? Do you plan that when an object changes its reachability 
to, say, weak, a cleanup method will be invoked? If so, why do we need another WeakReference?
Can't we just use the weak reference we have on Plumbing? In such case, the


        Plumbing.unregisterProxy(this);

we have on Proxy.finalize() can be invoked as part of such post-weak processing.

> Sometime people use a separate thread for that. Another possibility
> would be to use an idle handler setup from the native side. A third
> option would be to poll the reference queue as a (generated) part of
> every JNI call.

The idle handler seems the best alternative to me, at least the one with less performance 
impact. On applications with high memory requirements, however, may the 3rd option
is the best. Anyway, we can offer this as a compilation or runtime option (maybe via a JVM
parameter or environment var?)

Cheers
Vreixo

PS: I'm glad to write to this list again! Congratulation to all of you for your hard work.


      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com