Adding loop primitives/optimizations (was Making Set/Dictionaryetc. loops more robust)

John M McIntosh johnmci at smalltalkconsulting.com
Wed Dec 1 22:16:09 UTC 2004


Ok, let's clarify a bit about the GC stuff. When you make a plugin  
call, the plugin has total control (in theory).
A GC event will not happen until you do a callback and ask for memory,  
or perhaps some other callbacks which result in allocating memory, I'm  
not sure we have a list handy.

Usually the plugin allocates an object(s) to store results as an  
example. If you do this then there is a call you can make to push and  
pop the locations  you care about
such that they will be sizzled to the new locations if memory is moved.  
  Perhaps we need a macro to say: 'allocate an object of this size and  
here are all the other objects my
plugin method knows about at the moment" and it will then generate the  
right things to prevent disaster.  Certainly more upfront than our  
current solution of mystic knowledge.

Failure to do this means at some point after multiple/millions of  
plugin calls you'll get unlucky and a memory move will occur when you  
allocate a new Oop, causing you to poke the wrong bits resulting in odd  
behavior/crashes at a later date.

I believe we had talked about a change to the GC so that if a plugin  
call is active we would not trigger a GC, I don't recall if we actually  
implemented that thought?

At this time it is not outlandish to think about having a class that  
would have a fixed storage attribute. The object header can move, but  
the data is fixed.
Most other Smalltalks support this. You can of course roll your own  
with malloc, don't forget to code finalization rules so you can free  
things when the instance is
GCed. Rules for become: on this might require some thought.

On Dec 1, 2004, at 1:56 PM, Joshua Scholar wrote:

> You keep talking about the performance hit of locking the array...
> I don't know what Slang support for garbage collection has been  
> written but
> all you need is something that should be free!  All you want is to  
> make sure
> that the array you're iterating over doesn't go away until after the
> iteration is done.
>
> One of these two things (some form of this is NECESSARY if you ever  
> want run
> bytecodes in parallel with Slang code or call bytecodes from Slang  
> code):
>
> 1.  The ability to register some Slang/C variables with the garbage
> collector so that what they point at will not be collected and so that  
> those
> variables will be updated if the object moves.
>
> or
>
> 2. The ability to register some variables Slang/C variables with the  
> garbage
> collector so that what they point at will not be collected and to lock  
> the
> object so that it will not be moved.  This could be more expensive.
>
> Also, because of the become: problems you either want a restriction so  
> that
> Slang/C variables are never replaced on become: (that might be good  
> enough).
> Or you want to make become replacement optional on a per/varible basis.
> ....
>
> Why should keeping an object from being collected be expensive at all?
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===




More information about the Squeak-dev mailing list