On Friday, August 2, 2002, at 06:30 PM, Arjen van Elteren wrote:

> Hi,
>
> I'm playing with building my own plugin. In this code objects are 
> instanciated and linked up, filling the reciever
> object of the primitive function. These questions came up... Will the 
> gc run during object creation ?. Will OOPs change when a gc runs during 
> these operations ?

The plugin itself runs synchronously, without any concurrent activity by 
the interpreter.  Thus, there are no other processes or threads running 
that could invoke gc by surprise.  It is often possible to do all of the 
object building a well-factored plugin might require prior to invoking 
the plugin procedure, although sometimes this might entail ancilliary or 
intermediate calls to effect.   Note that Smallinteger objects (but not 
other integers) do not ever invoke gc.

 From time to time, it will be necessary or convenient to have the plugin 
procedure actually build a smalltalk image that requires generation of a 
non-SmallInteger object.  This is feasible for many standard string 
objects, such as ByteArrays and Strings using the interpreter proxy.  
These operations DO, in fact, invoke a GC, and WILL, in fact, mess with 
OOPS.  This means that every call to one of these object builders will 
require re-accessing any non-static (SmallInteger) oops from the 
parameter stack (at pain of all kinds of yicky and indetectible bugs).

For oops not easily or cheaply accessable from the stack  is an 
interpreter proxy method that will stack and unstack oops, so you simply 
stack the oops, generate your gc-able actions, and unstack the oops in 
reverse order.

The TestInterpreterPlugin provides a syntactic structure that greatly 
facilitates retaining oops stored in local variables, doing all the 
stacking and unstacking in code generation.

Hope this helps.