From: chromatic <[EMAIL PROTECTED]>
Date: Sun, 24 Feb 2008 19:13:50 -0800
On Sunday 24 February 2008 18:41:23 Bob Rogers wrote:
> Granted, and it's tough to make a PMC truly read-only until after it's
> completely initialized . . .
>
> There's a similar problem for accessors and setters. Again, that's
> solveable with more code or more cleverness.
>
> So, you're saying it is legal to invoke a setter on a constant PObj? In
> what sense then is that PObj a constant?
That depends. Is a hash declared with:
.const Hash foo
... constant as a reference or a referent or an aggregate or some
combination of all three?
No fair; I asked you "What *is* the purpose of constant PMCs?" first.
;-} The purpose and the definition have to agree.
In fact, we've been batting around several definitions of "constant"
rather loosely, with a few more waiting in the wings. I suggest we
decide which of these are useful to Parrot, and nail down the
terminology now, so we don't confuse ourselves (mostly me). Here are my
candidates:
"immutable" -- immune from being changed at the bytecode level. An
object could be marked immutable, and then mutable again (but some
objects may not allow this, particularly singletons). Immutable objects
are not treated specially by garbage collection. (I don't think this is
useful to Parrot per se, but may be useful to HLL implementors.)
"pure" -- immune from garbage collection. As a practical matter,
this means that it must be immune from change, and any other objects it
points to must themselves be pure. Once created, an object can only be
"purified" or "impurified" by copying.
I can think of a few others, but these are the two that I think could
be useful to Parrot. WDOT?
> BTW, that is the strategy used by most Lisp systems (and they don't
> bother fixing up the old objects). Typically, there is an internal
> "purify" function that makes its argument pure (and therefore read-only)
> by copying it recursively into pure space . . .
That seems like a better approach. At the point we know we want to take a
PObj out of the possibility of GC, we can decide then and there. That might
be the right approach altogether -- I like how it separates the
responsibility for purifying things out of object construction.
And it seems to stand a chance of working for loading PBC constants.
What other cases are there to worry about?
> So I gather that the purpose of read-only PMCs in the current design is
> something other than GC efficiency.
I think it *is* for GC efficiency, but like a lot of pieces of Parrot
over the years, it's a preliminary implementation based on a
preliminary design and needs some refactoring toward a fuller design.
Hmm. That's a kind way of putting it. Half-implementing an
optimization is a rather dubious tactic, even when it's not in something
as drop-dead critical as the garbage collector. (IMHO; of course,
nobody asked me.)
> 2. What would be the cost of storing constant PMCs in the normal
> pool, and having GC treat them normally? From what you say, speed is
> probably not an issue. And any non-GC purposes of constant PMCs ought
> not to require special GC treatment. On the other hand, the benefit may
> be to squash a whole nasty class of GC bugs.
* O(n^2) gets a bigger n as we mark and sweep more PObjs
Why n^2? I thought the current GC was O(# live ptrs) for the mark phase
plus O(# objs total) for sweep?
* we have more work to do to *find* the PObjs we need to mark, as some of
them are in bytecode segments and others are elsewhere
Seems to me you've already concluded that we have more work to do to
deal with those pesky variable constants. True?
Only the latter concerns me at all. Mark and sweep isn't the world's most
performant GC system anyway, and our implementation has some naive spots
itself (walking entire arenas to clear live flags and check custom destroy
flags is one).
Allison's GC spec uses in incremental mark scheme with tri-coloring.
I'm sort of hopeful we can get at least to a copying scheme for the
sweep.
-- c
That sounds much nicer. So I imagine we are looking for a stopgap here?
Perhaps the immediate goal should be to get a simple, ugly, reliable GC
working now, in anticipation of a better one later?
-- Bob
