[Vm-dev] who is bak?

Tobias Pape Das.Linux at gmx.de
Thu Oct 1 07:41:36 UTC 2015


Hi Eliot,

On 01.10.2015, at 03:17, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi Tobias,
> 
>     it's potentially a tricky issue for the RPython VM.  I finally fixed the source of the issues with the BalloonPlugin under simulation.  Bastian had changed it from
> 
> BalloonEngineSimulation>>#loadWordTransformFrom: transformOop into: destPtr length: n
> 	"Load a float array transformation from the given oop"
> 
> 	| srcPtr wordDestPtr |
> 
> 	false ifTrue:
> 		[^super loadWordTransformFrom: transformOop into: destPtr length: n].
> 
> 	srcPtr := interpreterProxy firstIndexableField: transformOop.
> 	wordDestPtr := destPtr as: CArrayAccessor.  "Remove float conversion shell"
> 	0 to: n-1 do: [:i | wordDestPtr at: i put: (srcPtr floatAt: i)]
> 
> to
> 
> BalloonEngineSimulation>>#loadWordTransformFrom: transformOop into: destPtr length: n 
> 	"Load a float array transformation from the given oop"
> 	| srcPtr wordDestPtr |
> 	false
> 		ifTrue: [^ super
> 				loadWordTransformFrom: transformOop
> 				into: destPtr
> 				length: n].
> 	srcPtr := interpreterProxy firstIndexableField: transformOop.
> 	wordDestPtr := destPtr as: CArrayAccessor.
> 	"Remove float conversion shell"
> 	0 to: n - 1
> 		do: [:i | wordDestPtr at: i put: (srcPtr floatAt: i) asIEEE32BitWord]
> 
> i.e. he changed
> 		wordDestPtr at: i put: (srcPtr floatAt: i)
> to
> 		wordDestPtr at: i put: (srcPtr floatAt: i) asIEEE32BitWord
> 
> This breaks some hidden optimization in the simulator where a BalloonArray has a handle on the "object" in the memory array and a cache of object values in a parallel simArray.  Unless the simArray's values correctly mirror those in the underlying heap object in the simulator's byte array, there are errors in the BalloonPluginSimulation.  I finally fixed these today, changing Bastian's code to
> 
> BalloonEngineSimulation>>#loadWordTransformFrom: transformOop into: destPtr length: n 
> 	"Load a float array transformation from the given oop"
> 	| srcPtr |
> 	srcPtr := interpreterProxy firstIndexableField: transformOop.
> 	"Use BalloonArray's float conversion shell.  It stores both the float bits into
> 	 the heap object, and the float object into the simArray.  This is needed for
> 	 correct simulation, otherwise there will be errors in BalloonArray>>floatAt:"
> 	0 to: n - 1 do: [:i| destPtr at: i put: (srcPtr floatAt: i)]
> 
> i.e. nuking the unneeded "wordDestPtr := destPtr as: CArrayAccessor." and changing the code to not send asIEEE32BitWord it the float ti be stored, because this is done inside the BalloonArray that is referred to via destPtr.
> 
> So.  I'm strongly confident my code above is correct for simulation but it may break the Python VM.  If it does then I think the RPython VM needs to avoid conflict with simulation subclasses of plugins, such as the BalloonEngineSimulation subclass of BalloonEnginePlugin, e.g. by using a subclassing naming scheme such as BalloonEngineForRPython or some such.  The simulator needs to work :-).
> 

RSqueak is actually not doing anything special, but reusing the Simulation code.
So as long as the simulation works, it should work for RSqueak, too :)

Best regards
	-Tobias

> Hope this makes sense.
> 
> On Wed, Sep 30, 2015 at 2:12 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
> Hi,
> 
> On 30.09.2015, at 22:57, Balázs Kósi <kosi.balazs at ezomer.hu> wrote:
> 
> > Hi,
> >
> > It's not me. Most probably you are looking for Bastian Kruck: http://www.bkruck.de/
> > ​
> 
> Yes, It is Bastian. He worked on this stuff earlier this year, So Eliot, you
> can also talk to Tim or me on that matter :)
> 
> Best regards
>         -Tobias





More information about the Vm-dev mailing list