[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] primitives, interrupts, allocation, and robustnes
From: |
Joe Marshall |
Subject: |
Re: [MIT-Scheme-devel] primitives, interrupts, allocation, and robustness |
Date: |
Fri, 17 Jun 2011 14:24:18 -0700 |
On Fri, Jun 17, 2011 at 1:56 PM, Taylor R Campbell <address@hidden> wrote:
>
> Another solution is to simply punt: if out of memory, don't try to GC,
> just abort to nearest. (There are good engineering reasons to do it
> this way, actually.)
>
> Er... Then the GC would never run. Maybe you were referring to
> something else? Secondary GC daemons?
Obviously, GC would be triggered by something else.
But the basic idea is to have multiple `regions' to cons in.
Each region would be a contiguous chunk of address space,
no two regions would overlap, but they need not tile. When
hitting the end of a region, simply allocate another and keep
going. If you cannot allocate more, halt.
Now the GC would be responsible for freeing regions by
condemning them and relocating the live objects elsewhere. If
it can keep pace (asymptotically), then you won't run out of regions
and therefore won't run out of memory.
--
~jrm
- [MIT-Scheme-devel] primitives, interrupts, allocation, and robustness, Taylor R Campbell, 2011/06/16
- Re: [MIT-Scheme-devel] primitives, interrupts, allocation, and robustness, Joe Marshall, 2011/06/17
- Re: [MIT-Scheme-devel] primitives, interrupts, allocation, and robustness, Arthur A. Gleckler, 2011/06/17