Front page | perl.perl6.internals |
Postings from August 2002
Re: Unifying PMCs and Buffers for GC
Thread Previous
|
Thread Next
From:
Dan Sugalski
Date:
August 4, 2002 14:11
Subject:
Re: Unifying PMCs and Buffers for GC
Message ID:
a05111b0ab97321d1db31@[63.120.19.221]
At 2:46 PM +0200 8/4/02, Peter Gibbs wrote:
>Mike Lambert wrote:
>
>> I'm currently favoring allowing for header pools on a per-type basis, not
>> just a per-size basis. This would give us a 'hash' pool. The pool
>> structure would contain function pointers for collection and/or dod
>> purposes. (stuff that would otherwise be in a PMC vtable.)
>I am very much in agreement with this concept in principle. I would like you
>to consider adding a name/tag/id field to all pool headers, containing a
>short text description of the pool, for debugging purposes.
I'm OK with this. Feel free to throw a patch in for it.
We should add in some introspection capabilities so the running
interpreter has access to it as well.
> > One idea, which is most closely in line with the current semantics, is to
>> add a pool pointer to every header. I've found a few times in the past
>> where such a pointer would have come in handy. This would allow us to call
>> the pool's mark() function, to handle stuff like pointing-to-buffers, etc.
>This is something I have done in my personal version, for buffer headers
>only at present (I have been mainly ignoring PMCs, as I believe they are
>still immature). I use it for my latest version COW code, as well as to
>allow buffer headers to be returned to the correct pool when they are
>detected as free in code that is not resource-pool driven.
I don't want pointers back to the pool header for space reasons. This
was why I was playing the alignment games at the beginning--with
sufficient control it's an OK thing to do.
If we limited the size of the arenas, I'd be willing to dedicate some
bits in the flag word to an offset count, though. (8 or 9 at most, so
I don't know that a limit of 256 or 512 headers per arena would be
worth it)
> > b) it allows us to make new types of buffer-like headers on par with
>> existing structures.
>On this subject, I would like to see the string structure changed to include
>a buffer header structure, rather than duplicating the fields. This would
>mean a lot of changes (e.g. all s->bufstart to s->buffer.bufstart), but
>would be safer and more consistant. Of course, strings may not even
>warrant existence outside of a generic String pmc any more.
Strings still warrant their own structure. They're more primitive
than PMCs, so I'd rather they stay that way.
> > a) no pmc type morphing. once in a pool, it stays in a pool. I don't see
>> this as a big loss, since type morphing is error-prone to begin with, imo.
>The main issue here would be the definition of pmc type, in an untyped
>language. We may need a PerlScalar pmc type, as that is what most Perl
>variables really are - if we stick to using pmc types based on current
>content, then we need to be able to morph between the different
>subclasses of PerlScalar as the contents change.
We don't need separate classes for Perl scalars--that they're done
that way is an accident of implementation. They could be a single
class with multiple vtables.
> > b) data members! Since not all pmcs are the same size, pmcs are able to
>> store data elements in their structure. This allows us to make a SV-like
>> PMC which stores str-value, int-value, float-value, etc. All without
>Okay, you were obviously thinking the same way!
There are sufficient advantages to fixed-sized PMCs that I'd rather
keep them that way.
>One option would be to use a limited set of physical sizes (only multiples
>of 16 bytes or something) and have free lists per physical size, rather than
>per individual pool. This would waste some space in each header, but may
>be more efficient overall.
For Bufferish things, that's fine. That's been the plan, just one
that hasn't been implemented yet
> > Finally....the unification of buffers and PMCs means that buffers can now
>> point to things of their own accord, without requiring that they be
>> surrounded by an accompanying PMC type.
>How about the other way round? If the one-size-fits-all PMCs were to be
>replaced by custom structures, then everything could be a PMC, and
>buffer headers as a separate resource could just disappear!
I'd rather not. Separate things for separate purposes.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk
Thread Previous
|
Thread Next