[<<][libprim][>>][..]
Fri Aug 14 11:09:11 CEST 2009

Packet Forth

It's becoming more clear to me that this is really a rewrite of PF.
The core idea is to be able to use linear+RC based memory management
for ``regime programs'' : code that performs some setup and then ends
up in an infinite loop with very predictable memory patterns.

The mistake I made in the first implementation is to assume that GC
isn't necessary.  Only after _first_ implementing a Scheme around the
primitive data types did I realize that this is really an essential
part: the synergy between a Scheme-like host and a linear stack
language that can mutate the GC-managed graph is essential to the
idea.  You need the first to provide "global memory" for the second.

Representing data.

The PF primitives should know about (``inside memory'').
    - constants
    - cons cells
    - RC managed leaf objects
    - opaque references to "outside" memory

The outside model, accessible from Scheme, needs to wrap RC managed
cells in an aref object.

An ``outside pointer'' TAG_OPAQUE is a data structure that is
GC-managed, but can be accessed abstractly from the inside.  It is
treated as a constant.

Basicly, in the linear model, everything could be opaque by default.
Essentially, PF doesn't need to care about managing anything else than
CONS cells and RC objects.

Now, whenever an RC value is made accessible to Scheme, it needs to be
wrapped in an aref, where the finalizer decrements the refcount.  Such
values are really meant to be kept local to the linear memory, but of
course it shouldn't be prevented to have them in the global space,
i.e. embedded in a piece of code as a constant.

This is not trivial however.  The refcounted object should be linked
to the Scheme wrapper, to keep the representation unique.  However,
this link must not become stale!

It looks like an rc struct needs to be a GC managed vector.
Conceptually it's not so hard: my difficulty is with the
representation.

        LIN -> GRAPH : rc++
        finalize:      rc--

        wrappers don't need to be unique!

The latter remark is key.

Looks like this works fine.



[Reply][About]
[<<][libprim][>>][..]