plugin code and garbage collection
Andrew C. Greenberg
werdna at mucow.com
Sat Aug 3 01:45:26 UTC 2002
On Friday, August 2, 2002, at 06:30 PM, Arjen van Elteren wrote:
> 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
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.
More information about the Squeak-dev