commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [collections] SoftRefHashMap (was RE: Avalon excalibur collec tions migration status)
Date Thu, 18 Jul 2002 06:38:29 GMT

----- 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>


Mime
View raw message