[Squeak-VMdev] Versiojn 4 changes

David T. Lewis lewis at mail.msen.com
Thu Apr 8 03:11:16 UTC 2004


On Thu, Apr 08, 2004 at 03:46:22AM +0200, Andreas Raab wrote:
> Which reminds about something totally unrelated but potentially *hugely*
> helpful:
> 
> How about if we disable GC in primitives?
> 
> This idea came back recently when we were talking about chasing GC
> problems - I don't even want to know how many places we have that aren't GC
> safe. And I wonder if it's even worthwhile to do this in primitives. If it
> is, we could still have a flag that basically "turns GC back on" (and this
> could be the default for quick-indexed primitives). Or maybe we just turn it
> off for any kind of named primitives.
> 
> Thoughts?

This would be very helpful for folks writing primitives, and would increase
the overall reliability of the VM+plugins. I cannot think of any legitimate
reason that an operation performed in a primitive should be doing something
that requires a GC. There are lots of places in SLANG primitives where the
author may or may not have fully understood memory allocation and garbage
collection. Eliminating the possibility of this kind of error would be a
really big win.

I have personally made errors of this kind on several occasions, and
I have no reason to think that I have eliminated all possible bugs in
everything that I've written. This is not good, and I'm sure that I am
not the only person who makes mistakes. Add enough primitives in enough
plugins by enough authors of various levels of experience, and we could
end up with ... well, Windows.

So yes, this is a really good idea.

Dave

p.s. I still remember a message that you (Andreas) send to me a
few years ago when I was trying to get some of the early OSProcess
primitives working. I did not have a clue as to what was going on
with GC and memory allocation in the primitives, and you straightened
me out. I think (but I do not know for sure!) that I fixed the
problems, but I would not be surprised if I missed one or two.




More information about the Squeak-dev mailing list