cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michel Lehon" <Michel.Le...@Outwares.com>
Subject RE: JDK1.2 MemoryStore & SoftReferences... Follow up.
Date Mon, 03 Apr 2000 12:41:50 GMT
> From: niclas@envision.asiaconnect.com.my
> [mailto:niclas@envision.asiaconnect.com.my]On Behalf Of Niclas Hedhman
>
> Michel Lehon wrote:
>
> > In the process the 'cleaned' objects are put on a 'finalization
> queue' that
> > seems to run asynchronously.
> > So the JVM runs out of mem, and then the finalization frees
> some... but it
> > is too late.
> > So it really looks like a dead end (for the moment).
>
> The answer is not in the finalize(). I am sure about that. There
> are tons of write ups from Sun, why that is useless.

Agreed, but had to be tried (just to be sure).

>
> Again, new ideas (I must admit that References are very badly
> documented from Sun);

I can't agree more.

>
> You create a SoftReference to the cache object and associate a
> ReferenceQueue;
>     ReferenceQueue queue = new ReferenceQueue();
>     SoftReference ref = new SoftReference( clearerProxy, queue );
>
> The GC will then release the clearerProxy out of the heap when he
> needs to.
> Now, I believe that the monitoring of the queue is the key to the
> solution.
> The GC is perhaps only enqueing reference objects if they are
> associated with a
> ReferenceQueue. Have this scenario been investigated, in respect
> of when the
> various methods in both the queue and reference object??

I tried to override 'enqueue()' on the Reference object... it does not get
called.
There are no offical method on the ReferenceQueue that can be overriden for
this purpose.
ReferenceQueue provides methods for polling (are there objects in the queue
?)
and removing objects from the queue (with or without a timeout).
There is no overridable method that could be called when the GC is adding an
object to the queue.


>
> Also, for the time being, it would perhaps be a good idea if the
> cache would
> have some memory setting on how much to use, and when getting
> close to that
> figure, start discarding old SoftReferences and IF the JVM runs
> out of memory,
> let it clear the remainding SoftReferences... I would call that
> an acceptable
> short-term solution, which we understand.

In fact I'm currently doing an implementation of MemoryStore which uses a
daemon thread to watch from time to time if memory is not running low (using
a few settings).
Should be posted in a few days (yep, I have a day job also).

> However, you say that HotSpot doesn't conform much to the
> SoftReference spec,
> then that should be addressed to the HotSpot team for correction or
> clarification.

It's in the pipeline. But the spec is vague enough for them not to bother
too much (look even a clever algorithm for SoftRefs is not mandatory).

>
> Niclas
>

Michel.


Mime
View raw message