[Vm-dev] primitivePerform (prim 83) | primitivePerformInSuperclass (100)

[David T. Lewis]

On Mon, Dec 12, 2011 at 01:59:11AM +0100, Stefan Marr wrote:
> 
> Hi Eliot:
> 
> Are there any known issues with primitivePerformInSuperclass?
> 
> And, ehm, what is the functionality that is supposed to be supported?
> 

I think you are missing some arguments for the primitive in your
#performSuper methods.

See the method comment in Object>>perform:withArguments:inSuperclass:
for a description of the functionality.

primitivePerformInSuperclass has been around for a long time, as the
last real update in the interpreter VM (aside from a recent minor
update for return code handing) is stamped 'di 4/12/1999'.

As a side note, #primitivePerformInSuperclass is exercised by
MirrorPrimiveTests>>testMirrorPerform which AFIK has no known problems
on Cog. That test fails on an interpreter VM because mirror primitive
support is not yet complete (http://bugs.squeak.org/view.php?id=7429)
but hopefully this will be resolved soon.

Dave

> I try with a doit, and everything works fine.
> But when it is used in a TestCase, it crashes :-/
> 
> """
> Exception Type:  EXC_BAD_ACCESS (SIGBUS)
> Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
> 
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   org.squeakfoundation.Squeak   	0x0004ef5a primitivePerformInSuperclass + 42
> 
> Thread 1:  Dispatch queue: com.apple.libdispatch-manager
> [...]
> """
> 
> 
> With regard to the supported functionality, I would expect it to mirror perform more or less exactly, but the image I use, only knows 'perform: selector withArguments: argArray inSuperclass: lookupClass' which uses an explict array for the arguments.
> However, from the doIt, the code below seems to work.
> And, well, when I use the debugger, it works of course too...
> 
> performSuper: aSymbol
> 	<primitive: 100>
> 	^ self perform: aSymbol withArguments: (Array new: 0) inSuperclass: self class superclass
> 
> performSuper: aSymbol with: anObject 
> 	<primitive: 100>
> 	^ self perform: aSymbol withArguments: (Array with: anObject) inSuperclass: self class superclass
> 
> 
> I also tried to put the code from the doit into a class, and see whether that indirection makes a difference, since I remember that you have some special treatment for doits in Cog, right?
> 
> Thanks
> Stefan
> 
> 
> On 08 Dec 2011, at 03:01, Eliot Miranda wrote:
> 
> > Hi Stefan,
> > 
> > On Wed, Dec 7, 2011 at 4:09 PM, Stefan Marr <squeak at stefan-marr.de> wrote:
> > 
> > Hi:
> > 
> > >From the current implementation, which I find in the interpreter, and from testing on Cog I assume that primitive 83, that is 'perform:', does easily handle an arbitrary number of parameters.
> > 
> > Is that correct, or does for instance Cog do something else? (it does not seem so)
> > 
> > That's correct. The primitive (InterpreterPrimitives>>primitivePerform) is written in terms of argumentCount and so should cope with any number of arguments up to the maximum (15 is the limit in CompiledMethod, 31 in the bytecode set I believe).
> > 
> > I am just asking, because the number of parameters of the Object>>#perform:with: variants goes only up to three. And, the comment does not mention it. (at least in a recent Pharo image)
> > 
> > Furthermore, I guess, there is an upper limit on the number of arguments with regard to frame size?
> > 
> > Not in the StackVM or the Cog VM since these are running on a stack, not in a context, and so there's always plenty of headroom to push args on the stack during a perform.  At least the method/bytecode set's limit on argumentCount is going to bite before the stack size.  Similarly with perform:withArguments:, as long as the number of arguments is <= LargeFrameSize (56 slots?) the primitive will push arguments.  Of course, the number of arguments must match the method that is found, and so the real limits are CompiledMethod's and the bytecode set's.
> > 
> > cheers,
> > 
> > 
> > Thanks
> > Stefan
> > 
> > --
> > Stefan Marr
> > Software Languages Lab
> > Vrije Universiteit Brussel
> > Pleinlaan 2 / B-1050 Brussels / Belgium
> > http://soft.vub.ac.be/~smarr
> > Phone: +32 2 629 2974
> > Fax:   +32 2 629 3525
> > 
> > 
> > 
> > 
> > -- 
> > best,
> > Eliot
> > 
> 
> -- 
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525