What exactly are you trying to do? When do you consider an object to be "used"? 

- Bert -

On 03.10.2010, at 12:12, Mariano Martinez Peck wrote:

Hi. I have a related question once again with this topic. I've changed Interpreter >> normalSend to something like this:

    "Send a message, starting lookup with the receiver's class."
    "Assume: messageSelector and argumentCount have been set, and that
    the receiver and arguments have been pushed onto the stack,"
    "Note: This method is inlined into the interpreter dispatch loop."
    | rcvr |
    self inline: true.
    self sharedCodeNamed: 'normalSend' inCase: 131.
    rcvr := self internalStackValue: argumentCount.
    ((self isIntegerObject: rcvr) not and: [hasToTrace])
        ifTrue: [
            self internalTurnOnUsedBit: rcvr.
    lkupClass := self fetchClassOf: rcvr.
    receiverClass := lkupClass.
    self commonSend.

So...if it is not a SmallInetger and if the flag is on, I turn on a bit.

The question is, if I send a normal message to a normal object. Example:

| anObject |
anObject := MyClass new.
anObject foo

Now...I am sure that "anObject" was marked with the bit. But what about:
a) the compiled method  MyClass >> #foo
b) MyClass

should they be marked?

In other words:

self deny: (unUsed primitiveGetUsedBit: anObject).
    self deny: (unUsed primitiveGetUsedBit: anObject class).
    self deny: (unUsed primitiveGetUsedBit: (anObject class >> #foo)).
     anObject foo.

    self assert: (unUsed primitiveGetUsedBit: anObject).
    self assert: (unUsed primitiveGetUsedBit: anObject class).
    self assert: (unUsed primitiveGetUsedBit: (anObject class >> #foo)).

should all the asserts pass?  I ask because I don't know how CompiledMethods are executed (they receive a normalSend like any other object?) nor how class are accessed.

Thanks in advance,


On Tue, May 11, 2010 at 5:43 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 11 May 2010 17:40, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
>> >
>> > Thanks Igor. I could see #class does not the normal way. It was logic as it already has the pointer there ;)
>> >
>> > Now I wonder...to avoid those special cases, do you think it makes sense to intercept in commonSend rather than commonSend ?  or it would be the same ?
>> >
>> err... commonSend or commonSend? i think it would be the same :)
> hahahah sorry, I meant commonSend instead of normalSend.
>> the other point, where you can try intercept a send is cache lookup.
> internalFindNewMethod  ?

I don't know, maybe :)

> Thanks
> Mariano