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
|