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.
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
vm-dev@lists.squeakfoundation.org