Re: Tonight's tradeoff

On Mon, 11 Mar 2024 09:32:40 -0700, Tim Rentsch
<tr.17687@z991.linuxsc.com> wrote:

George Neuner <gneuner2@comcast.net> writes:
>

On Sun, 10 Mar 2024 14:29:52 -0400, George Neuner
<gneuner2@comcast.net> wrote:
>
>

Problem is - whatever [GC] you choose - it will be wrong and have bad
performance for some important class of GC'd applications.

>
"bad performance" may mean "slow", but also may mean memory use much
higher than should be necessary.

>
Understood.  And there are other relevant metrics as well, as
for example not throughput but worst-case latency.

If latency is the primary concern, then you should use a deterministic
system such as Baker's Treadmill. 

Treadmill essentially is just a set of linked lists, and collectio
operations like marking and sweeping simply move blocks from one list
to another.  But you pay for that determinism with space - compared to
other systems, Treadmills have a lot of per-block metadata.

Note that for allocating and freeing to be deterministic, a Treadmill
has to work with fixed size blocks.  But you can run multiple
Treadmills for common block sizes, with a catchall for big blocks.
Some malloc/free style allocators already work like this, using
separate lists for some commonly requested block sizes.

Depending on how you handle the metadata, Treadmills also are amenable
to coalescing free space and/or compacting the heap / working set. But
note that these types of operations can't be made deterministic.