Cees De Groot wrote:
I'm hardly a VM hacker, but:
On 6/6/06, Andreas Raab andreas.raab@gmx.de wrote:
sqInt addToVmRoots(sqInt *newArray, sqInt newCount, sqInt *oldArray);
why not oldCount as an argument? Or zero-terminated arrays for that matter?
oldCount is irrelevant since the VM won't copy the contents of newArray; it will merely keep a reference to it (the array really is under control of the plugin). Therefore all we need is the reference to oldArray (this also goes for reallocating via realloc() - just remember the old pointer before you do that and pass it into the above to update the oop array).
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.
Cheers, - Andreas
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? 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.
Cheers, Hans-Martin
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
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Hans-Martin Mosner