<br><br><div class="gmail_quote">On Tue, Nov 11, 2008 at 8:25 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Igor -<br>
<br>
I think it's worthwhile to step back a bit and think about what you're actually trying to achieve here. While it may be possible to replace push/popRemappableOop with just push/pop it seems to me that you are just replacing one set of obscure rules with an even more obscure set of rules. Considering that such a change would also require rewriting every single plugin it strikes me as being of little practical relevance.<br>
<br>
If you are trying to simplify the programming model and improve the robustness of plugins the better approach is to make push/popRemappableOop be effective no-ops by disabling GCs in primitives. This way you don't need to remap oops (except in places where you may want to run an explicit GC such as primitiveNew) and can keep all existing plugins with no change. The only requirement for this is a bit of extra headroom which we have already (it is reserved for forwarding blocks in full GCs) and it seems reasonable to take a small bite out of that reserved space to trigger a GC after the primitive completes.<br>
<br>
Cheers,<br><font color="#888888">
- Andreas</font></blockquote><div><br></div><div>This is the way to go. I've done some of this for the Stack interpreter. It doesn't disable GC in the new and new: primitives, but it does disable GC at all other points, such as allocating a context or closure during normal execution, or when flushing a stack page's frames to heap contexts to make the page available. These "system" allocations will not GC, but instead set a flag saying GC is needed when an allocation exceeds a threshold. The GC will then occur at the next frame-building (non-primitive) send. The VM uses the stack page limit as an event check flag. Every frame build must check the stack limit for overflow. Events such as GC needed or IO poll needed simply smash the stack limit and the one test for stack overflow also serves for breaking out to do a GC or poll for IO.</div>
<div><br></div><div>VisualWorks has always worked this way. It works well.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888"></font><div>
<div></div><div class="Wj3C7c"><br>
<br>
Igor Stasenko wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2008/11/11 Igor Stasenko <<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
btw, concerning failures to allocate memory (and therefore primitive<br>
failure when building up the complex oop).<br>
An allocation followed by #storePointer:ofObject:withValue: .<br>
If you take a look, there is no checks if object is valid or having<br>
enough slots for storing value at given offset.<br>
So, in case if allocation fails, and return invalid object (or<br>
non-object), there is 100% guarantee that it will corrupt object<br>
memory.<br>
So, what the difference between corrupting object memory and<br>
corrupting the stack?<br>
Btw the latter case can be detected much faster than first one.<br>
<br>
<br>
</blockquote>
oh, wait, i just checked: allocation never fails.<br>
If it fails, VM is bailing out immediately. :)<br>
In this case, i insist that, if carefully written, primitives could<br>
use the argument/receiver slots in stack for building up thier complex<br>
oops as response.<br>
<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br>