Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Since this has come up again, ...
[ FYI: I was starting implementing this, based on a general traverse
vtable with callback functions. Two patches got backed out by
Dan after some discussion in PM ]
> ... and it's apparent that the last time around
> I wasn't sufficiently clear, it's time to go through this again, and for
> the final time.
I'd be really happy, if you could go through my concerns mentioned in
the summary in the thread:
Subject: Re: [RfC] vtable->dump
Date: Thu, 4 Sep 2003 12:31:08 +0200
> ... (I will beat this thing into the ground by the time we're
> done)
Sorry for the inconvenience and being ignorant ...
> PMC *thaw(interpreter, STRING *)
This should IMHO be able to create constant PMCs out of metadata, e.g.
for subroutine objects. So there should be some means to tell thaw() to
create PMC(s) in the constant_pmc_pool.
> The chill and warm runtime methods take a PMC or a frozen representation
> of a PMC (respectively) and provide a human readable version of that PMC.
I dunno, why chill() is superior to dump() or pretty_print(), but the
name doesn't really matter.
> 1) Freezing at the destruction level may *not* use any additional memory
> for object traversal
What is "Freezing at the destruction level"? Is this anyhow related to
destruction ordering?
> Note that I do *not* want to have multiple object traversal systems in
> parrot! We have one for DOD, and proposals have ranged upwards from there.
> No. That is *not* happening--the chance for error is significant, the
> side-effects of the error annoying and tough to track down for complex
> cases (akin to the trouble with tracking down GC issues), and just not
> necessary. (Perhaps desirable for speed/space reasons, but desirable
> isn't necessary)
DOD's mark() routine has different requirements then a general
traverse() for freeze(), chill(), clone(), and destruction ordering.
Using just mark() will have these side effects that you want to avoid.
A general traverse() can be depth first of breadth first, mark() isn't
required do have any specific ordering as long as it sets live bits
everywhere.
mark() is called permanently in a running interpreter, that does non
trivial things. There are shortcuts for scalars, DOD is highly optimized
not to destroy cache coherency. Using mark() also implies to back out
my small PMC patches. All the advantages of smaller scalars are gone
then.
While freeze() and friends have to pull in each PMC into the cache, just
setting the live bit on a PMC hasn't. Further: Lukes proposal for
speeding up timely destruction puts objects either in front or at the
end of the next_for_GC chain. This IMHO implies that mark() is unusable
as your general and solely iterator.
> ... This is something that's hidden under a number of layers
> of API, so regardless of the outcome it doesn't affect the assembly, PMC,
> or runtime API.
So when its hidden, I really don't understand, why you are insisting on
an (IMHO) suboptimal design.
> The thread-safety is an issue,
While all schemes aren't thread-safe from user level (e.g.
manually sorting an array containing shared PMCs, while it gets
frozen), your scheme isn't thread-safe at low-level, as the next_for_GC
pointer inside the PMC is used as a duplicate marker. But if a user
changes shared resources its a user problem. We only guarantee atomic
updates per PMC (s. P6E p 86f by Dan).
> Dan
Comments addressing all these issues are highly welcome,
leo
