You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Jack, Paul" <pj...@sfaf.org> on 2002/07/15 23:39:50 UTC
RE: [collections] SoftRefHashMap (was RE: Avalon excalibur collec
tions migration status)
> It is possible to find a lot of patches in archyve for this
> class, some I
> posted myself a half year ago.
I'll go hunting for them (Btw, the mail archive seems broken).
> > 1. PhantomReference.get() always returns null. This means
> > that a mapwith phantom keys or phantom values is more or less
> > useless. (The keys or values would disappear as soon as you
> > put them in the map! For instance for phantom keys,
> > map.put("key", "value") followed by map.containsKey("key")
> > would always return false.)
>
> It useless if used without ReferenceQueue.
> Documentation :
> "Soft and weak references are automatically cleared by the
> collector before being added to the queues with which they
> are registered, if any. Therefore soft and weak references
> need not be registered with a queue in order to be
> useful, while phantom references do. An object that is
> reachable via phantom references will remain so until
> all such references are cleared or themselves become unreachable."
Still, in the context of a Map, if you surround the keys or values
with PhantomReferences, those keys or values disappear. A Map whose
keys or values aren't visible isn't much of a Map, so I don't see a
use for PhantomKeyMap or PhantomValueMap.
> > 2. A map with soft keys would do the same thing as a map with soft
> > values: When memory is running low, the garbage collector
> > would remove mappings from the map. So it doesn't seem to be useful
> > to allow people to specify both soft keys and soft values, since they
> > do the same thing.
>
> It is not the same. Garbage collector would not remove
> mapings if they are reacheble. Keys can be unreacheble and values can be
> reacheble at the same time. SoftValueMap's are used for cache.
That's a good point. A SoftKeyMap could be useful in the case where there
are strong references to the values somewhere outside of the Map, but no
strong references to the keys...
Now I'm thinking that ReferenceMap is useful for weak keys (in a pre-JDK1.3
application), weak values, soft keys, soft values...One class for four
cases.
So, maybe we should just eliminate its ability to use phantom references
and submit it...but I still like Stephen's idea of using decorators for
the soft and weak values.
Thoughts?
-Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] SoftRefHashMap (was RE: Avalon excalibur collections migration status)
Posted by Juozas Baliuka <ba...@centras.lt>.
Sory, it was cache interface.
----- Original Message -----
From: "Juozas Baliuka" <ba...@centras.lt>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Tuesday, July 16, 2002 8:24 AM
Subject: Re: [collections] SoftRefHashMap (was RE: Avalon excalibur
collections migration status)
>
> Hi,
> You are rigth about Phantom references, they are usefull but not for
maps,
> Soft and Weak references do almost the same. I think it is good just to
fix
> "purge" in SoftRefHashMap and to implement MRU stuf (to hold strong
> references on MRU values ).
> I attached cache implementation, map can be implemented the same way.
>
>
> > > It is possible to find a lot of patches in archyve for this
> > > class, some I
> > > posted myself a half year ago.
> >
> > I'll go hunting for them (Btw, the mail archive seems broken).
> >
> > > > 1. PhantomReference.get() always returns null. This means
> > > > that a mapwith phantom keys or phantom values is more or less
> > > > useless. (The keys or values would disappear as soon as you
> > > > put them in the map! For instance for phantom keys,
> > > > map.put("key", "value") followed by map.containsKey("key")
> > > > would always return false.)
> > >
> > > It useless if used without ReferenceQueue.
> > > Documentation :
> > > "Soft and weak references are automatically cleared by the
> > > collector before being added to the queues with which they
> > > are registered, if any. Therefore soft and weak references
> > > need not be registered with a queue in order to be
> > > useful, while phantom references do. An object that is
> > > reachable via phantom references will remain so until
> > > all such references are cleared or themselves become unreachable."
> >
> > Still, in the context of a Map, if you surround the keys or values
> > with PhantomReferences, those keys or values disappear. A Map whose
> > keys or values aren't visible isn't much of a Map, so I don't see a
> > use for PhantomKeyMap or PhantomValueMap.
> >
> >
> > > > 2. A map with soft keys would do the same thing as a map with soft
> > > > values: When memory is running low, the garbage collector
> > > > would remove mappings from the map. So it doesn't seem to be useful
> > > > to allow people to specify both soft keys and soft values, since
they
> > > > do the same thing.
> > >
> > > It is not the same. Garbage collector would not remove
> > > mapings if they are reacheble. Keys can be unreacheble and values can
be
> > > reacheble at the same time. SoftValueMap's are used for cache.
> >
> > That's a good point. A SoftKeyMap could be useful in the case where
there
> > are strong references to the values somewhere outside of the Map, but no
> > strong references to the keys...
> >
> > Now I'm thinking that ReferenceMap is useful for weak keys (in a
> pre-JDK1.3
> > application), weak values, soft keys, soft values...One class for four
> > cases.
> >
> > So, maybe we should just eliminate its ability to use phantom references
> > and submit it...but I still like Stephen's idea of using decorators for
> > the soft and weak values.
> >
> > Thoughts?
> >
> > -Paul
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
Re: [collections] SoftRefHashMap (was RE: Avalon excalibur collections migration status)
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
You are rigth about Phantom references, they are usefull but not for maps,
Soft and Weak references do almost the same. I think it is good just to fix
"purge" in SoftRefHashMap and to implement MRU stuf (to hold strong
references on MRU values ).
I attached cache implementation, map can be implemented the same way.
> > It is possible to find a lot of patches in archyve for this
> > class, some I
> > posted myself a half year ago.
>
> I'll go hunting for them (Btw, the mail archive seems broken).
>
> > > 1. PhantomReference.get() always returns null. This means
> > > that a mapwith phantom keys or phantom values is more or less
> > > useless. (The keys or values would disappear as soon as you
> > > put them in the map! For instance for phantom keys,
> > > map.put("key", "value") followed by map.containsKey("key")
> > > would always return false.)
> >
> > It useless if used without ReferenceQueue.
> > Documentation :
> > "Soft and weak references are automatically cleared by the
> > collector before being added to the queues with which they
> > are registered, if any. Therefore soft and weak references
> > need not be registered with a queue in order to be
> > useful, while phantom references do. An object that is
> > reachable via phantom references will remain so until
> > all such references are cleared or themselves become unreachable."
>
> Still, in the context of a Map, if you surround the keys or values
> with PhantomReferences, those keys or values disappear. A Map whose
> keys or values aren't visible isn't much of a Map, so I don't see a
> use for PhantomKeyMap or PhantomValueMap.
>
>
> > > 2. A map with soft keys would do the same thing as a map with soft
> > > values: When memory is running low, the garbage collector
> > > would remove mappings from the map. So it doesn't seem to be useful
> > > to allow people to specify both soft keys and soft values, since they
> > > do the same thing.
> >
> > It is not the same. Garbage collector would not remove
> > mapings if they are reacheble. Keys can be unreacheble and values can be
> > reacheble at the same time. SoftValueMap's are used for cache.
>
> That's a good point. A SoftKeyMap could be useful in the case where there
> are strong references to the values somewhere outside of the Map, but no
> strong references to the keys...
>
> Now I'm thinking that ReferenceMap is useful for weak keys (in a
pre-JDK1.3
> application), weak values, soft keys, soft values...One class for four
> cases.
>
> So, maybe we should just eliminate its ability to use phantom references
> and submit it...but I still like Stephen's idea of using decorators for
> the soft and weak values.
>
> Thoughts?
>
> -Paul
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
RE: [collections] SoftRefHashMap (was RE: Avalon excalibur collec
tions migration status)
Posted by "Michael A. Smith" <ma...@apache.org>.
On Mon, 15 Jul 2002, Jack, Paul wrote:
> > It is possible to find a lot of patches in archyve for this
> > class, some I
> > posted myself a half year ago.
>
> I'll go hunting for them (Btw, the mail archive seems broken).
which archive?
> Still, in the context of a Map, if you surround the keys or values
> with PhantomReferences, those keys or values disappear. A Map whose
> keys or values aren't visible isn't much of a Map, so I don't see a
> use for PhantomKeyMap or PhantomValueMap.
agreed. Phantom references are pretty much useless in this case. At
least, I really don't see a use for them.
> Now I'm thinking that ReferenceMap is useful for weak keys (in a pre-JDK1.3
> application), weak values, soft keys, soft values...One class for four
> cases.
As long as it sits over a hash based map, this should work.
> So, maybe we should just eliminate its ability to use phantom references
> and submit it...but I still like Stephen's idea of using decorators for
> the soft and weak values.
I like the idea of using a decorator as well. Unfortunately, it doesn't
work -- at least for the soft/weak key cases. You absolutely need
control over the map when dealing with the keys.
Consider passing in a Tree based map to a weak key decorator, a TreeMap,
for example. You want to add an object to the map, so you wrap it in a
reference, but then, the map doesn't know how to handle the key because
its no longer comparable. You could pass through the implementation of
compareTo to the underlying object, but as soon as the reference is
cleared, there's no way to tell without traversing *both* sides of the
tree to figure out which direction to go (not to mention that you also
need to clean up the tree because there's a removed node in the middle
of it).
At least with a hash based map, you can cache the hash code so that you
get to the correct bucket (and passing the equals method through to the
underlying object in the reference object shouldn't effect things too
much).
So, as much as I'd like to see decorators for all four cases, it is
really only partially practical in the weak/soft value case.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>