Re: [Sbcl-devel] Static conses

[David L. R. <ra...@cs...>]

Hi Doug,

Ah, it sounds like the solution is in the immobile space, beautiful.
I'll read up on the immobile space.  We're currently running on linux
x86-64, and I'm guessing immobile is implemented for that platform.
It also sounds like the immobile approach requires your suggested
improvements to the GC.

As you point out, if a "static cons" is only accessible via the
remembrance of its index, then we hope and expect it will be GC'd.
And correspondingly, if a "static cons" is pointed to by another
"non-static cons", then the "static cons" will not be GC'd.

Thanks for the idea about using a defstruct.  As you observe, we
really do need "static conses" (hash conses) to be conses.  So, we
should probably look into the immobile approach.

Thanks,
David

On Wed, May 31, 2017 at 10:04 AM, Douglas Katzman <do...@go...> wrote:
> Immobile space objects are "static" in the sense that you want - immobile
> but not actings as roots per se.
> But on second thought I wonder about your requirement that object addresses
> (or "indices", in your writeup) be invertible - this seems to imply that you
> can concoct an object out of the thin air based *only* on remembering its
> index. If that's really true, then it seems they must all be retained
> forever.
> If what you mean however is that the object is only reconstructible provided
> that it is otherwise reachable from a GC root, then the immobile space will
> do what you want.
>
> If you're not wedded to the notion that the objects with which you do hash
> consing are actually conses (i.e. indistinguishable from ordinary cons
> cells), then I suspect it might already work to define them as a defstruct
> and put them in immobile space.
>
>
> On Wed, May 31, 2017 at 10:58 AM, David L. Rager <ra...@cs...>
> wrote:
>>
>> Hi Doug,
>>
>> Unfortunately, you're right.  Ideally a static cons could still be
>> garbage collected once it becomes unreachable.  I'm not sure where
>> this leaves us.  I'll try to read some more about what static means in
>> the context of SBCL.  If you improve the mark-and-sweep collector in
>> that way, would it then be reasonably possible to weaken the
>> definition of static to include objects that are dynamic in lifespan?
>>
>> Thanks,
>> David
>>
>> On Wed, May 31, 2017 at 9:44 AM, Douglas Katzman <do...@go...> wrote:
>> > I will probably generalize the mark-and-sweep collector to allow 2-word
>> > objects (cons cells).
>> >
>> > Just to be clear on one thing: "static" for you means static in
>> > placement,
>> > and not also static in lifetime, right? The static space approach that
>> > was
>> > mentioned creates objects which once allocated act as permanent roots.
>> > I
>> > don't think that's what you want.
>> >
>
>