cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michel Lehon" <>
Subject RE: JDK1.2 MemoryStore & SoftReferences... Follow up.
Date Sun, 26 Mar 2000 10:07:00 GMT
> Niclas Hedhman wrote:
> Sent: Saturday, March 25, 2000 07:27
> To:
> Subject: Re: JDK1.2 MemoryStore & SoftReferences... Follow up.
> Michel Lehon wrote:
> > WeakReference: Used to keep a link to an object without preventing the
> > garbage collector from reclaiming it at ANY time. In JDK 1.2.2
> (under Win98
> > & WinNT4WS, tested both with classic WM & HotSpot2RC1) testing
> shows that
> > WeakReferences are cleared as soon as possible (of course after all hard
> > refs are cleared).
> > This does not make them suitable for the MemoryStore as Stored
> objects would
> > be removed from the Store immediatly.
> The definition of WeakReferences are not exactly what you are
> describing. The
> WeakReferences DOES NOT prevent the GC to reclaim the object, as a hard
> reference does.
> Use; One hard reference that owns the object, and N weak
> references that knows
> about the object until the hard reference is dropped. Very useful
> for Listener
> patterns for instance.

That is what I meant, but my explanation was not so good....
Since the use I'm looking for is caching... weak refs are useless since they
get cleared soon after the last hard ref is dropped.

> > SoftReference: Same as WeakReference, except that they are
> supposed to be
> > reclaimed when the System memory runs low but before throwing an
> > OutOfMemoryException.
> This is correct.
> > In fact the
> > HotSpot2RC1 VM is even worse as it clears the SoftReferences before the
> > memory runs low (it looks like HotSpot treats SoftRefs and WeakRefs the
> > same).
> Well, I think that HotSpots GC is much more complicated than some
> benchmarking
> can esily detect. HotSpot has a nursery and a long-time heap, and
> I guess the
> algorithms for releasing the object from each are different, both
> in respect of
> traditional hard references and weak/soft references.

I never said HotSpot's GC was easy to understand... I was even careful using
'looks like', because I know my simple tests can't show the whole picture.

The problem seems to be that the SoftReference is cleared even tough the VM
is far from running out of memory.
With the classic VM, SoftReferences are kept intact as long as there is
memory available (I tested by limiting available memory with -Xmx).

> Now, what can I propose...
> Does the GC  call the clear() method?? You say it does not...
> Does it not call
> any methods that can be overridden?

I'll check that.

> If the GC calls any method upon low memory, then just create some dummy
> object(s) which upon being called from the GC determine which of the hard
> referenced cached objects should be released, i.e a delegated algorithm.

I'll give it a try, even if no overriden methods of the SoftReference are
called, I can still use a finalizer to get a chance of clean up.

More info in a few days (I'll try to be faster than last time ;-)).

> Wish I had some time for this.

Me too.

> Niclas

Michel Lehon
SAS DataWarehousing & Web Enablement.

View raw message