Message-Id: <9703181554.AA46238@idse.heidelbg.ibm.com>
To: Kohler Markus <kohlerm@betze.bbn.hp.com>
Subject: Re: Weak pointers
In-Reply-To: (Your message of Tue, 18 Mar 97 10:09:38 GMT.)
<199703181009.LAA23108@betze.bbn.hp.com>
Date: Tue, 18 Mar 97 16:54:19 +0100
From: Wolfgang Lux <lux@heidelbg.ibm.com>
> [...]
> > You can use them to implement hash-consing. Assume you have some tre=
e
> > data structure. If you want to share the nodes wherever possible, yo=
u
> > can put every created node into a hash table. Then when you are abou=
t
> > to create a new node, you first look in the hash table to see if the
> > same node has already been created. If this is the case, you return
> > the old one from the hash table instead of creating a new one.
> > =
> > But the above prevents the GC from collecting the nodes when they
> > become unused, because they will always be reachable from the hash
> > table. If you use weak pointers in your hash table, the GC will be
> > able to deallocate the dead nodes, but you still can have access to
> > the live ones through the weak pointers.
> > =
> =
> I'm not sure if it makes sense to implement such a tree with weak point=
ers. =
> To be honest, I think it's not a good idea to do so. =
> =
> The problem is that if you delete an element in the tree it may be that=
the =
> hash table still points to the node, because there was no garbage colle=
ction =
> yet. It could be possible that you would still find the entry trough th=
e hash =
> table.
Surely this is possible, but I do not see why this should be a problem. =
It will just prevent you from creating an identical copy of an element =
which had been present in the hash table.
> =
> IMHO the real solution is to implement a delete method for the tree whc=
ih =
> takes care of all that internal pointers. =
> =
No. The delete method for the tree is the wrong place. You would link =
your tree implementation hardly with the use of the hash table and =
disallow the use of the data structure without a hash table or with =
another hash table implementation. This does not seem good software =
engineering practice to me.
BTW, in implementing such a method you would have to implement some =
kind of weak pointer yourself. A data structure might be an element in =
more than one tree so would have to keep reference counts as well to be =
sure that you can remove a data structure from the hash table.
I would admit that weak pointers are some dirty kind of feature in the =
language and I'm not quite happy that they. It is very easy to write =
programs in the presence of weak pointers, whose outcome is completly =
random. But in some cases like the one of Damien's example it may be =
the least dirty one.
> By the way, I know what I'm speaking about because we have here an appl=
ication =
> using the same idea to implement some kind of cache. I does not work pr=
operly =
> because nobody knows at which point of time the garbage collector throw=
s way =
> the objects. =
Sure. But this only demonstrates the fact, that you have to use weak poin=
ter with care. If you work with objects where a data structure which is r=
ecreated differs from a data structure that is refetched from the cache, =
weak pointers are really not applicable. (And maintaining cache consisten=
cy is not trival at all in this case!)
Regards
Wolfgang
----
Wolfgang Lux WZH Heidelberg, IBM Germany
Phone: +49-6221-59-4546 Fax: +49-6221-59-3500
Internet: lux@heidelbg.ibm.com Office: mazvm01(lux)