Keeping oops across primitives

[Andreas Raab]

Hans-Martin Mosner wrote:
> Andreas Raab wrote:
> 
>> Why not NULL terminated? I'm planning on using NULL as the "undefined 
>> entry" in the oop array. Since this code is managed by some other C 
>> code that seems preferrable to nil (although the plugin could store 
>> nil just as well). But it probably will be valuable for the C code to 
>> be able to say "clear this entry" via storing NULL and having the VM 
>> skip this is fairly simple.
> 
> Perhaps it would be easier for the VM if you'd use an immediate value 
> for the undefined entry so that all entries were valid oops?

Like I was saying, the plugin can do that (just store nilObj in the 
slot). I'm just not going to require it because the NULL test is going 
to be faster (and more easily understood by the C programmer).

> I don't know how exactly the code for this would be merged into the 
> existing GC stuff, but to me at least it feels like it would be easiest 
> if there were as few as possible special cases, and the GC already 
> distinguishes between immediate values and object pointers.

Actually, that's not relevant here - we're talking about remapping 
storage locations (variables) that are managed by the plugin. So code 
would do the logical equivalent of:

   /* in markAndTraceInterpreterOops */
   if(pluginArray[i]) markAndTrace(pluginArray[i]);

   /* in mapInterpreterOops */
   if(pluginArray[i]) pluginArray[i] = remap(pluginArray[i]);

Whether the contents of pluginArray[i] is an immediate or not isn't 
really a concern for that code.

Cheers,
   - Andreas