2008/11/11 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> Okay, but what about reusing the arguments stack slots?
>
> And what if there are none? There are tons of primitives returning complex
> objects (arrays, rectangles) that take no arguments.

there is always at least one argument - receiver.

>
>> In most cases, when primitive generating response its:
>> - already checked everything (can't fail)
>
> Primitives can fail for other reasons than argument mismatches.
>
yes, but what will happen if primitive fails on allocating new oop?
if you see the examples i shown, primitives in their epilogue never
check success flag after allocation, they blindly filling the complex
oop with values, and then returning it, inevitably damaging the stack
by pops/pushing result oop. This makes impossible to restore stack
into 'untouched' state for passing correct arguments into method if
primitive fails.
So, a proposed scheme having same flaws as previous in this case.

>> - already evaluated results
>> - arguments no more in use
>
>> And , since primitive should return only single object, its easy to
>> prove, that it requires MAXIMUM SINGLE temp value on stack, which
>> needs to be remapped.
>
> Not true either. ObjectMemory>>allocate: remaps the classOop so a depth of
> AT LEAST 2 is required even for your example. There are almost certainly
> other places that have a similar effect.
>

Interpreter + ObjectMemory having 7 senders of pushRemappableOop:, 3
of them in primitives.
It can use own , single remappable oop for its needs, but not stacked buffer.

>> see? its even less lines of code :)
>
> Except that it doesn't work.
>
err.. where i made a mistake? I think the rewrites will work 1:1 as
old code, except that they not using remappable buffer.

> Cheers,
>  - Andreas
>

-- 
Best regards,
Igor Stasenko AKA sig.