[Vm-dev] Re: [Pharo-project] [squeak-dev] CogVM binaries as per VMMaker.oscog-eem.157/r2550.

[Mariano Martinez Peck]

On Thu, Apr 19, 2012 at 6:06 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
> On Thu, Apr 19, 2012 at 12:55 AM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>>
>> On Thu, Apr 19, 2012 at 6:08 AM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>
>>> http://www.mirandabanda.org/files/Cog/VM/VM.r2550/
>>>
>>> CogVM binaries as per VMMaker.oscog-eem.157/r2550.
>>>
>>> Stack/CoInterpreter/Cogit:
>>> Implement proper bounds checking for byte access to compiled
>>> methods.  Raise errors for accesses outside initialPC to size.
>>>
>>> CoInterpreter:
>>> Provide a thorough flush primitive for CompiledMethods that discards all
>>> machine code and makes sure that any contexts using the method have bytecode
>>> pcs.  Primitive #215 (same as 116 in the Stack VM).  This is much slower than
>>> 116 (flushCache) since it has to enumerate over all heap contexts.
>>>
>>>
>> Excellent. Does it mean we should implement something like this:
>>
>> CompiledMethod >> flushCache
>>     "Tell the interpreter to remove all references to this method from
>> its method lookup cache, if it has one. In addition, it provides a thorough
>> flush primitive for CompiledMethods that discards all machine code and
>> makes sure that any contexts using the method have bytecode
>> pcs.
>>     This primitive must be called whenever a method is redefined or
>> removed."
>>     <primitive: 215>
>>     self simpleFlushCache
>>
>>
>> CompiledMethod >> simpleFlushCache
>>     "Tell the interpreter to remove all references to this method from
>> its method lookup cache, if it has one. This primitive must be called
>> whenever a method is redefined or removed."
>>
>>     <primitive: 116>\
>>
>
> No.  215 is extremely expensive, because it scans the entire heap looking
> for contexts using the method, and in the common case of redefining a
> method it is unnecessary.  It is only necessary if you modify a method
> still in-use; read the comment of the attached method.
>
> Further, I would prefer to update the Interpreter to implement primitive
> 215 using primitive 116, i.e. in the Interpreter's primitive table have both
>
> (116 primitiveFlushCacheByMethod)
> ...
> (215 primitiveFlushCacheByMethod) "primitiveVoidVMStateForMethod in the
> CoInterpreter"
>
> This is what I've done in the StackInterpreter.  In fact, we need to put
> in time to bring the Interpreter's primitive set into agreement with Cog.
>
>

Ok, I understand. Now, primitive 215 #primitiveVoidVMStateForMethod
receives a CompiledMethod so we implement #voidCogVMState there. However, I
see there is also primitive 214 #primitiveVoidVMState.  Should we ALSO add
something like

voidCogVMState
    "Void all internal VM state in the stack and machine code zones
<primitive: 214>
^self primitiveFailed


But implemented in SmallttalkImage/VirtualMachine  ??


thanks!


>
> So I'm expecting we will have
>
> voidCogVMState
> "Tell the VM to remove all references to any machine code form of the
> method.
>  This primitive must be called whenever a method is in use and modified.
>  This is
>  more aggressive (and *much* more costly) than flushCache since it must
> search
>  through all context objects, making sure that none have a (hidden)
> machine code pc
>  in the receiver.  Since modifying a method will likely change the
> generated machine code,
>  modifying a method (rather than redefining it) requires this more
> aggressive flush."
>
> <primitive: 215>
>  ^self primitiveFailed
>
> flushCache
> "Tell the interpreter to remove all references to this method from its
> method lookup cache, if it has one.  This primitive must be called whenever
> a method is defined or removed.
>  NOTE:  Only one of two selective flush methods needs to be used.
> Squeak 2.2 and earlier uses 119 (See Symbol flushCache).
>  Squeak 2.3 and later uses 116 (See CompiledMethod flushCache)."
>
> <primitive: 116>
>
> or
>
> voidCogVMState
> "Tell the VM to remove all references to any machine code form of the
> method.
>   This primitive must be called whenever a method is in use and modified.
>  This is
>  more aggressive (and *much* more costly) than flushCache since it must
> search
>   through all context objects, making sure that none have a (hidden)
> machine code pc
>  in the receiver.  Since modifying a method will likely change the
> generated machine code,
>   modifying a method (rather than redefining it) requires this more
> aggressive flush."
>
> <primitive: 215>
>  ^self flushCache
>
> flushCache
> "Tell the interpreter to remove all references to this method from its
> method lookup cache, if it has one.  This primitive must be called whenever
> a method is defined or removed.
>  NOTE:  Only one of two selective flush methods needs to be used.
> Squeak 2.2 and earlier uses 119 (See Symbol flushCache).
>  Squeak 2.3 and later uses 116 (See CompiledMethod flushCache)."
>
> <primitive: 116>
>
>
>>
>>
>> If you have a better name for #simpleFlushCache please let me know.
>> if you agree, I will open an issue for this.
>>
>> Cheers
>>
>>
>>
>>>
>>> Provide an xray primitive for CompiledMethod that answers if a method has
>>> machine code, and if so if it's machine code is frameless, and/or refers
>>> to a young object.  No primitive number.  Used to test the above.
>>>
>>> Make printOopShort: print Association keys.  Useful for
>>> longPrintOop:, and hence printReferencesTo: etc.
>>>
>>> Mac OS: add fflush to debug printing in sqMacUIEventsUniversal.c so output
>>> appears promptly.
>>>
>>> Fix the annoying bogus error messages from the mprotect calls by getting the
>>> length arg to mprotect right.
>>>
>>> Add version infor for the Cross/plugins tree.  Add a -version switch to win32
>>>
>>> --
>>>
>>> best,
>>>
>>> Eliot
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>
>
> --
> best,
> Eliot
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120427/1b1b2154/attachment.htm