[Vm-dev] normalSend, specialObjectsArray and VM

[stephane ducasse]

always the same:
	we want a kind of new LOOM (Melt in Java) where unused objects are move to disc.

Stef

On Oct 3, 2010, at 1:03 PM, Bert Freudenberg wrote:

> On 03.10.2010, at 12:45, Mariano Martinez Peck wrote:
> 
>> On Sun, Oct 3, 2010 at 12:42 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>  
>> What exactly are you trying to do?
>> 
>> hehehe sorry. I am trying to "detect unused objects".
> 
> What for?
> 
>>  When do you consider an object to be "used"? 
>> 
>> 
>> When it receives a message. This is why I changed #normalSend
>> 
>> Thanks in advance,
>> 
>> Mariano
> 
> Neither the class nor the compiled method "receive a message". Plus there are many ways an object "appears" to receive a message but isn't really. E.g. a Float won't receive #+ because that is short-circuited in the bytecodes. A super send does not use "normalSend". Etc.
> 
> Judging from your test cases, if an objects is just passed as an argument, you do not consider it to be used. What if you send it the #class message? What if you identity-compare it (==)?  Should that count as "used"?
> 
> Maybe if you let us in on the bigger picture we could help you better.
> 
> - 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:
>>> 
>>> 
>>> normalSend
>>>     "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,
>>> 
>>> Mariano
>>> 
>>> 
>>> On Tue, May 11, 2010 at 5:43 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>> 
>>> On 11 May 2010 17:40, Mariano Martinez Peck <marianopeck at 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
>>> >
>> 
>> 
>> 
> 
>