Getting back to push/pop remappable oop

 
Hi list,
>From previous discussion, where Eliot mentioned about removal push/pop
remappable oop oddity and modifying GC to make it work w/o it, i'm
just thinking
- there was no need in having these methods from the very start.
Any oop at any time can be temporary pushed on stack and then popped
back again using #pop:/#push: methods.
Of course, primitives need to be careful to not override the
arguments, which can be reused in method when primitive fails - so
they should push values past the arguments.
But in most cases, a primitive creates new object(s) at the point,
where it needs to form a returned value - at this point most things is
done: arguments is read & already popped out of stack, values
calculated etc etc. So it is safe to put temporary values on stack,
making GC happy and without need in use push/popRemmappableOop.

Going in this way, there is no need in adding safety schemes, like
reserving extra free space and delaying GC before primitive finishes
working.

--
Best regards,
Igor Stasenko AKA sig.

 
Igor Stasenko wrote:
> - there was no need in having these methods from the very start.
> Any oop at any time can be temporary pushed on stack and then popped
> back again using #pop:/#push: methods.
> Of course, primitives need to be careful to not override the
> arguments, which can be reused in method when primitive fails - so
> they should push values past the arguments.

This won't work. Stack frames are limited in size and sized in the image
based on however much space is required by the byte codes without any
regards of potential additional space needed by primitives (which is
variable). And, since primitives are executed before activation (meaning
that the "primitive stack" would have to share the frame with the caller
method) every frame would have to reserve the maximum additional stack
space any single primitive might require.

Cheers,
   - Andreas