At 9:03 PM +0100 11/1/04, Leopold Toetsch wrote:

Works for me. We probably need to make sure that everything's in
place for keys to tag the individual key elements properly too.

Any reason that the destroy entry's insufficient? That's what I'd
intended it to do, at least.

I can see thinking about changing the scheme we use to destroy
things, certainly (like, say, putting the pmcs that need destruction
in a queue, tagging them as having been queued, run the queue and
trigger the destroy method, tag them as having been destroyed, then
if they come up as dead in the next round of DOD assume they're
garbage), but I'm not sure we need to split finalization and
destruction. Not that I mind, certainly, if there's something I'm
missing. :)
--
                                Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk

I've been looking into Python's dict code (see links below), and it
actually is pretty sweet.  Everything is stored in a single flat array
that doubles in size whenever it reaches 2/3 full.

Notable features of Python dicts:

Only things that are immutable are expected to have hash functions.
Tuple, for example, does have a __hash__ function; list does not.  Nor
does dict.  Unless Parrot has an equivalent notion, it will have to
clone the key.

There also is interesting semantics with respect to values (or more
precisely, the semantics of an assignment statement).  At the moment
pirate is consistent with Python on the following, but pie-thon is not:

   a=1
   d={"a":a}
   a=2
   print d

   a=[1]
   d={"a":a}
   a[0]=2
   print d

The "correct" result is:

   {'a': 1}
   {'a': [2]}

With pie-thon, the results are:

   {'a': 2}
   {'a': [2]}

- Sam Ruby

http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Objects/...
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Objects/...

There is one entry in the hash structure:

  Hash_key_type key_type;

That should suffice. I don't think, we should mix STRING and PMC keys in
one hash - or only with care: a STRING "foo" and a String PMC "foo" hash
to the same hash value. An Integer PMC C<1> and a STRING key "1" are
different.

These two have different usage patterns.

destroy() is needed commonly to free memory. finalize() is currently
needed to close file handles and clear active timer PMCs.

When we have objects with finalizers, we have to run the finalizers in
order from most derived down the parent chain. So as you state, we've to
defer destruction, store these objects with finalizers somewhere, sort
them, run user code to finalize objects and so on.

Doing that all in the destroy vtable is tedious especially, when user
code is involved too. The finalize vtable is overridable, the destroy
isn't. A split makes this functionality much cleaner.

leo

On Nov 2, 2004, at 12:41 AM, Leopold Toetsch wrote:

Maybe, but not necessarily. The case of loops means that we cannot
always do this cleanly (no "top" of the chain), and the fact that
finalizers may modify the topology of the object graph also makes this
a bit ill-defined. There are several possible approaches, ranging from
very conservative to very aggresive. Two real-world approaches already
used are: make no guarantees about finalization order--only guarantee
that a finalizer will be called at some point after an object becomes
unreferenced, with no guarantees about ordering, and no guarantees that
it will not be called if the object has already be re-rooted (Java);
or, do graph-ordered finalization, and never call the finalizers of
objects which are in loops (the Boehm collector does something along
these lines, I believe).

Other objects are impacted as well--any object reachable from a
finalizable object must wait for reclamation until finalizers have
fired.

I think what's bothering me about this is that I think part of the idea
is to move closing of filehandles and such into destroy()--right? That
sounds good--don't get rid of this resource until it's certain nothing
will try to use it (eg, things which want to log a message during their
finalization would use a filehandle). But I don't think this really
solves it. For one thing, there will be similar-in-functionality code
coming up in HLL's (doing some orderly shutdown of connections, which
involves more than just closing the filehandle), and this will have to
happen in a finalizer (since that's the only HLL option), which will
feel "too early" in some cases. And even in a destroy(), you might want
to do some I/O, and whether this will work will depend on whether the
filehandles have been closed yet, and the same ordering concerns
re-emerge.

So I think the split would help, in a sense, but only be a partial
solution to an unsolvable problem, and therefore maybe is not very
elegant. So I'm a bit on the fence.

(And in my parlance, just to be clear: "finalizers" are called after an
object becomes un-referenced, and could re-root an object;
"destructors" are called when the object is actually having its memory
re-claimed--when it is going away for sure. No user code can be called
from a destructor in the Parrot case, because of the possibility of
re-rooting, and because of other constraints which may exist at
destroy-time.)

JEff