[Larceny-users] GC limits?

[William D Clinger]

On 11 February, Sven wrote:
> Is there a size limit for the standard GC?
> A long running process of mine (compiled with svn Petit Larceny)
> crashes when reaching sizes between 1.2 and 1.3 GB VSize

The gc should not have any limits other than those
imposed by Larceny's 32-bit pointers and the OS.
Larceny hasn't been tested extensively near those
limits, however, so this is an important bug report
for us.

> (with my GC settings: -load 4 -size1 16M -size2 32M -size3 512M) and
> sizes between 830 MB and 890 MB (with default GC settings).
> The machine runs Linux, has no relevant ulimits, and owns 3GB RAM.

There are several possibilities, mostly having to
do with the OS denying Larceny's request for more
memory or with the overflow from 31-bit pointers
to 32-bit.

With 1.2 gigabytes of live data, the next full gc
will require 2.4 gigabytes, which some operating
systems are unwilling to give to a 32-bit process
regardless of ulimits.  If the OS refuses to give
Larceny the memory needed for a collection, then
Larceny should exit with a Larceny panic.

Another possibility is that some bug we don't know
about causes Larceny to crash when the high bit of
some pointer is set.  That kind of bug is especially
likely with Petit Larceny, which compiles to C and
uses semi-portable casts from pointer to int and
various right shifts.

Today Sven wrote:
> If I use the sassy backend, the process needs less memory and never
> crashes. So, I will prefer this backend.

The Sassy backend generates smaller and tigher code
than Petit Larceny, since it bypasses the C compiler.
It would be nice to know whether the bug went away
just because the heap size became smaller, or because
we have a bug in Petit Larceny that isn't shared by
the native-code-generating versions.  We'll try to
figure that out.

Will