[Pharo-project] RoarVM - Pharo and Squeak on Multicore

Igor Stasenko siguctua at gmail.com
Wed Nov 3 22:36:48 CET 2010


On 3 November 2010 23:28, Stefan Marr <pharo at stefan-marr.de> wrote:
> Hi Igor:
>
> Lets look at the current code, and let me explain what currently happens on the RoarVM.
>
> "Code as in Pharo 1.0"
> eventLoop
>        "Fetch pending raw events from the VM.
>         This method is run at high priority."
>        | eventBuffer |
>
>        "STEFAN: this is fine, it is an optimization but should not be a problem (Squeak has that also outside of the inner loop)"
>        eventBuffer := Array new: 8.
>
>        [true] whileTrue: [
>                | type window |
>                self waitForInput.
>
"so, placing: "

eventBuffer at: 1 put: EventTypeNone.

"should solve the promblem?"

>                [
>                "STEFAN: here things break on RoarVM
>                         the problem is, that eventBuffer is not filled with anything useful if there is no new event.
>                         In case there is non new event, the content of eventBuffer seems to be the same content as it was before.
>                         However, on all other forks, RoarVM seems to supply the right 'there is no event (EventTypeNone = 0)' value to eventBuffer"
>                self primGetNextEvent: eventBuffer.
>                type := eventBuffer at: 1.
>                type = EventTypeNone]
>                        whileFalse: [
>                                "Patch up the window index in case we don't get one"
>                                window := eventBuffer at: 8.
>                                (window isNil
>                                        or: [window isZero])
>                                        ifTrue: [eventBuffer at: 8 put: 1].
>
>                                self signalEvent: eventBuffer]]
>
>
> I will have a look at what happen inside the VM later.
>
> Best regards
> Stefan
>
>
> On 03 Nov 2010, at 22:07, Igor Stasenko wrote:
>
>> On 3 November 2010 21:48, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>>> can you open a bug entry?
>>>
>> it was my idea putting
>>
>> eventBuffer := Array new: 8.
>>
>> outside of loop, since InputEventSensor anyways copying it before
>> placing in queue:
>>
>> handleEvent: evt
>>       self queueEvent: evt shallowCopy.
>>
>>
>> i have no idea, what can go wrong with it when running under RoarVM.
>>
>>> Stef
>>>
>>>>> Hi
>>>>> Yes, is on a x86_64-linux, Debian squeeze.
>>>> I use that setup on one of the machines, too.
>>>> Should not be problem with the 32bit libraries.
>>>>
>>>>> The problem was some libraries... but with a good symbolic links compile
>>>>> fine, but, Pharo 1.2 doesn't works, it freezes.
>>>> Pharo works currently only with a single core, I think.
>>>> And there might be one of my latest fixes missing in the current change set for Pharo.
>>>> The event processing is broken somehow. I have a work-around (below) but still need to figure out why the eventBuffer is not filled in correctly by the primitive.
>>>>
>>>> Wouldn't be surprised if it is again Pharo's compiler *grml*. The other forks work, so I doubt that it is the primitive/VM.
>>>>
>>>>
>>>> !InputEventFetcher methodsFor: 'events' stamp: 'StefanMarr 10/31/2010 21:45' prior: 47875547!
>>>> eventLoop
>>>>       "Fetch pending raw events from the VM.
>>>>        This method is run at high priority."
>>>>
>>>>
>>>>       [true] whileTrue: [
>>>>               | window eventBuffer type |
>>>>               self waitForInput.
>>>>               [eventBuffer := Array new: 8.
>>>>               self primGetNextEvent: eventBuffer.
>>>>               type := eventBuffer at: 1.
>>>>               ((type = EventTypeNone) or: [type isNil])]
>>>>                       whileFalse: [
>>>>                               "Patch up the window index in case we don't get one"
>>>>                               window := eventBuffer at: 8.
>>>>                               (window isNil
>>>>                                       or: [window isZero])
>>>>                                       ifTrue: [eventBuffer at: 8 put: 1].
>>>>
>>>>                               self signalEvent: eventBuffer]].
>>>>               RVMPrimitives printOnConsole: 'ended event loop'.! !
>>>>
>>>>
>>>>>
>>>>> Someone could it on a x86_64-linux ?
>>>>>
>>>>> Thanks!
>>>>> El mié, 03-11-2010 a las 18:18 +0100, Stefan Marr escribió:
>>>>>> Hello Felipe:
>>>>>>
>>>>>> On 03 Nov 2010, at 17:45, Felipe Ignacio Valverde Campos wrote:
>>>>>>> Hi, how can i compile this on a x86_64 environment ?
>>>>>>> until now i hace some problems with lstdc++
>>>>>>
>>>>>> RoarVM does not support compilation as 64bit.
>>>>>> So you will need the 32bit compatibility libraries.
>>>>>>
>>>>>> I don't remember doing something out of the ordinary but in the worst case some paths are guessed badly in src/makefiles/configure or src/makefiles/Makefile.common
>>>>>>
>>>>>> What is the exact system you are running on, some Linux is suppose?
>>>>>>
>>>>>> Best regards
>>>>>> Stefan
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Estudiante de Ingeniería Civil en Computación
>>>>> Departamento de Ciencias de la Computación
>>>>> Universidad de Chile
>>>>>
>>>>> http://www.dcc.uchile.cl/~fvalverd/public_key.asc
>>>>
>>>> --
>>>> 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 regards,
>> Igor Stasenko AKA sig.
>>
>
> --
> 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 regards,
Igor Stasenko AKA sig.




More information about the Pharo-project mailing list