Re: [Help-smalltalk] Understanding the object layout.

[Paolo Bonzini]

On 05/04/2010 07:52 PM, Mathieu Suen wrote:
> > Because it allows to move the object data without rewriting all
> > the pointers in the OOPs.  The only case in which we have to scan
> > the whole OOPs is for one-way become.
>
> Ok so I guess the GC compactor is faster. But it imply also that the
> oop_s structure should not be compact only the object_s is compact.

All oop_s structures are the same size, so it's easy to reuse them with 
a simple freelist without leaving space in the heap.

> Are the oop_s and object_s structure in the same heap space?

No.

> Does you keep null terminal string?

No, only when needed (see _gst_to_cstring in libgst/dict.c).

> Ok thanks for you help. I will try to understand how the GC is
> implemented. And also it could be interesting to discuss on the way
> to implement the copy-on-write feature. I guess is might have some
> impact on the object layout.

Maybe, or maybe not.  I wondered if it is enough to create another 
subclass of CharacterArray, add some flags to be checked by the #at:put: 
primitives.  And of course some creative use of #become:. :-)

But a warning is needed: it is a hard feature.  I'm sure you could 
manage, but there is also other work that can be useful and a more 
gentle start. For example:

1) making a binary format for Smalltalk source code that already 
includes bytecode etc. and teaching the VM to load it.  Between the 
Smalltalk compiler and gst-convert, there would be a lot of existing 
code to leverage.  Maybe it fits your expertise better too?

2) making an Objective-C bridge; there is Squeak code out there to take 
inspiration from.  Bonus points for making it work with both the Apple 
and GNU runtimes.

3) think of what _you_ would need if you were writing scripts in 
Smalltalk (bindings, whatever) and do that.  This will hopefully provide 
insights in both GST and the VM that you can use for other projects.

Paolo