[squeak-dev] A couple of memory management related questions

Igor Stasenko siguctua at gmail.com
Tue Jun 15 21:55:59 UTC 2010

Hi, Eliot

On 16 June 2010 00:17, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi All,
>     I've started working on a new GC for Cog and have a few questions.
> 1. does anyone have a copy of Joel Bartlett's J. F. Bartlett. A
> generational, compacting collector for C++. In E. Jul and N.-C. Juul,
> editors, OOPSLA/ECOOP ‘90 Workshop on Garbage Collection in Object-Oriented
> Systems, Oct. 1990. ?

Not this in particular. But about GC, i found a very interesting idea
about run-time
garbage collection.
The idea is simple: at each allocation of N bytes, GC marks N*k bytes
of object memory (where k>1).
So, the mark phase overhead is proportionally distributed among memory
allocations, which makes
a usual allocation a bit slower, but having much less delays in
garbage collection cycles, since
once it marked everything, it just doing a sweep (& compaction).

> 2. what's the largest number of classes you've got in your most complex
> image and/or what's the largest number of classes you're ever created in an
> image?  a.k.a.  is 64k classes enough (16 bits), or is 1m classes enough (24
> bits)?

I would really like to not have a hard limit for number of classes in VM.
This is for implementing a prototype-based stuff, where each object is
an instance of itself, and hence
it acting as class.
For running a usual smalltalk system, i think the limit could be even
less - like 4095 or 8095 classes.
But i think that VM should not impose a hard limit on the number of classes.

> 3. do you have any personal recommendations, or example code, of systems
> that combine generation scavenging and/or compaction with object pinning?

Never explored this direction :)
How about making everything pinned from start (i.e. use a heap-based
algorithms for allocation)?
Then you don't have to do compaction, and do it only when saving an image.

> TIA,
> Eliot

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list