----- Original Message -----
From: "Jack, Paul" <pjack@sfaf.org>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Sent: Thursday, July 18, 2002 4:14 AM
Subject: RE: [collections] SoftRefHashMap (was RE: Avalon excalibur collec
tions migration status)
> > Ummm.. I'd go so far as to say that in *all* cases, WeakReferences
> > would behave differently than SoftReferences. WeakReferences are
> > cleared once an object is only weakly reachable. SoftReferences are
> > *not* cleared when they are only softly reachable -- they are cleared
> > when memory constraints demand. That's two very different
> > behaviors and it doesn't matter whether the GC runs incrementally or
> > in a stop-the-world manner.
>
> No, Joshua has a point here. WeakReferences aren't automatically
> cleared the instant the object becomes weakly reachable; the garbage
> collector first has to notice that there aren't any hard references
> to the object. If the gc is "stop-the-world" and only
> runs when there's demand for memory, then it won't notice weakly
> reachable objects, and won't clear any WeakReferences, until there's
> memory demand. Essentially they'd be acting like SoftReferences,
> without the bias you mention below.
>
> But even in that presumably rare case, the behavior would still be
> different enough to warrant the inclusion of both weak and soft
> references in ReferenceMap, so I guess the point is moot.
Ok, it is good to have both. GC implementations can be changed and both
cases are useful.
>
>
> > > We could use an internal SequencedHashMap to store strong
> > > references, actually, since it only keeps the x most recent
> > > mappings.
> >
> > I think it's unnecessary. If the JVM needs the memory, it needs the
> > memory. The VM should not be clearing SoftReferences if it
> > doesn't need the memory. It is true, though, that there are no
> > constraints on *which* soft references are cleared, but the API spec
> > says that "Virtual machine implementations are, however, encouraged
> > to bias against clearing recently-created or recently-used soft
> > references." Thus, you already have a SequencedHashMap type thing
> > for those recently created/used references. Yeah, ok, recently
> > created isn't as useful as recently used. But I think it's better
> > to leave it up to the application of SoftRefHashMap to hold onto
> > strong references rather than build it into SoftRefhashMap itself.
>
> Yeah, the more I think about it, there are many different ways people
> might want to keep hard references. For instance, they might want to
> keep hard references to objects that were created/used within the past
> five minutes, but soft references to older objects.
>
> Point being, I think people could use ReferenceMap as a building block
> for more complicated memory-sensitive caches if they needed to, but
> building those complications into ReferenceMap doesn't make sense. So,
> I won't add any freaky MRU stuff.
Yes MRU stuff can be implemented by user, in some "decorator", but I think
It is good to add some implementation or documentation ( it is almost the
same in this case :) as "tip" for user.
>
> I'll probably submit ReferenceMap minus phantoms in about an hour...
>
I reviewed it, I can't see any problems at this time.
> -Paul
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|