Buffer PMC RFC

Andrew Whitworth wknight8111 at gmail.com
Fri Jun 4 00:23:07 UTC 2010


+1 from me. That sounds like a very good idea.

There are some other things I would like to add to such a PMC, eventually:

* pin/unpin (especially if we have a copying/compacting collector)
* mmap (especially to make a bit of memory executable, which would be
very very useful in JIT)
* memory-mapping files (I know mmap does this on *nix)
* Ability to freeze/thaw other PMCs to the buffer instead of a STRING
might be nice too.

--Andrew Whitworth



On Thu, Jun 3, 2010 at 7:57 PM, Vasily Chekalkin <bacek at bacek.com> wrote:
> Hello.
>
> After recent digging into GC guts, work on immutable strings, masak++
> work on strings building I would like to propose next changes in
> parrot core.
>
> 1. Remove "buffers" (which is string-like mutables). They adds a lot
> of complexity to GC (finding them, compacting, etc). And they are
> sharing same storage as strings which isn't good in immutable strings
> world.
>
> 2. Introduce Buffer/BufferIterator PMCs. Buffer will have methods like:
>  a) .push_byte, .push_word for pushing sized integers into it. (May
> be .push_u8, .push_u16 will be better)
>  b) .get_byte, etc to get sized integer at position
>  c) .set_byte
>  b) .encode(encoding) to "convert" buffer into String with predefined
> encoding. Actually it will just create such string and validate it.
>
> BufferIterator will be used as "cursor" in "packfile" functions.
>
> If no-one objects I'm going to implement it over weekend.
>
> --
> Bacek
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>


More information about the parrot-dev mailing list