August 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo : the power hog.

by Sven Van Caekenberghe

On 10 Aug 2014, at 20:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > It took you a long time to upgrade, next month you'll be behind again ;-) > > Anyway, this has been reported before: > > http://forum.world.st/Pharo-on-Mac-OS-X-10-9-Mavericks-td4716590.html > > And even long before that: > > http://forum.world.st/Hungry-Pharo-td4717636.html Euh, I meant: http://forum.world.st/Waste-of-CPU-Power-by-polling-events-td3054458.html 2010 ! > BTW, it is not UI related as it is visible on servers as well. > > On 10 Aug 2014, at 20:10, kilon alios <kilon.alios(a)gmail.com> wrote: > >> I have just upgraded my macbook air to Mavericks and I noticed now that Activity Monitor has an energy tab that shows which apps consume most energy and Pharo is on No1 spot for idle apps. >> >> 1) Pharo - > 50-60% >> >> 2) Chrome (7 tabs open) -> 10% >> >> 3) Blender (3d app) -> 15% >> >> emacs, itunes , maps etc close to 0% >> >> The only way to compete with pharo is playback a youtube video that spikes energy to 80 or play a 3d game. >> >> I assume Morphic is quite heavy on resources. >

Aug. 10, 2014

Re: [Pharo-dev] Pharo : the power hog.

by Sven Van Caekenberghe

It took you a long time to upgrade, next month you'll be behind again ;-) Anyway, this has been reported before: http://forum.world.st/Pharo-on-Mac-OS-X-10-9-Mavericks-td4716590.html And even long before that: http://forum.world.st/Hungry-Pharo-td4717636.html BTW, it is not UI related as it is visible on servers as well. On 10 Aug 2014, at 20:10, kilon alios <kilon.alios(a)gmail.com> wrote: > I have just upgraded my macbook air to Mavericks and I noticed now that Activity Monitor has an energy tab that shows which apps consume most energy and Pharo is on No1 spot for idle apps. > > 1) Pharo - > 50-60% > > 2) Chrome (7 tabs open) -> 10% > > 3) Blender (3d app) -> 15% > > emacs, itunes , maps etc close to 0% > > The only way to compete with pharo is playback a youtube video that spikes energy to 80 or play a 3d game. > > I assume Morphic is quite heavy on resources.

Aug. 10, 2014

Pharo : the power hog.

by kilon alios

I have just upgraded my macbook air to Mavericks and I noticed now that Activity Monitor has an energy tab that shows which apps consume most energy and Pharo is on No1 spot for idle apps. 1) Pharo - > 50-60% 2) Chrome (7 tabs open) -> 10% 3) Blender (3d app) -> 15% emacs, itunes , maps etc close to 0% The only way to compete with pharo is playback a youtube video that spikes energy to 80 or play a 3d game. I assume Morphic is quite heavy on resources.

Aug. 10, 2014

Re: [Pharo-dev] [Vm-dev] Re: mustBeBooleanMagicIn can crash the vm

by Camille Teruel

On 10 aoÃ»t 2014, at 19:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Nicolai, > > > On Sun, Aug 10, 2014 at 9:39 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Hi Eliot, > > I am pretty sure this is not a vm issue :) > > The mustBeBooleanInMagic: creates a method on the fly and executes it with the > a context as argument. > The "ThisContext" is not the "thisContext", but the argument of the generated method. > > This is the bytecode of the generated method: > > 17 <00> pushRcvr: 0 > 18 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 22 to 23 > 22 <76> pushConstant: 1 > 23 <7D> blockReturn > 24 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 28 to 29 > 28 <75> pushConstant: 0 > 29 <7D> blockReturn > 30 <F0> send: ifTrue:ifFalse: > 31 <7C> returnTop > > The original method is > > foo > ^ notABool1 ifTrue:[1] ifFalse:[0] > > The generated method compiles this part > notABool1 ifTrue:[1] ifFalse:[0] > > to bytecode without the jumpFalse optimization. > The problem is that the receiver for the ifTrue:ifFalse send is accessed through > pushRcvr:0, whereas the thisContext is not the context of the original method anymore. > > Ah, now I know what's going on. Thanks. I like this experiment very much. > > How do you extract the blocks from the method? Do you decompile or simply recompile from source or...? We just recompile the ast message node that triggered the error without optimizations and some rewriting (temps and returns). Right now it works only for 'if' messages. For 'while' messages I'm thinking about sending #truthValue to the value of the receiver block. > Have (any of) you looked at implementing the mustBeBooleanMagic by interpreting the bytecodes that already exist in the method via some specialized interpreter instead of compiling a method on the fly? No but that would be interesting indeed :) Another solution is to cache the generated methods somewhere instead of recompiling each time. > > > Nicolai > > > 2014-08-10 17:34 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Nicolai, > > please try and remember to invlude vm-dev when you see a VM issue... > > > On Sun, Aug 10, 2014 at 7:34 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > There is a certain risk, that the mustBeBooleanMagicIn method rewrite can crash the > vm > Issue 13805 > > Since you're using the Opal compiler ca you add the description of the bytecode (aCompiledMethod symbolic) to the issue? I'll try and take a look soon but want to be sure I'm debugging the relevant code. > > The receiver of the rewritten method is the "nonboolean" value receiving the > ifTrue:ifFalse: message. But the rewritten method can include > instvar accessor and self sends of the original method. > > We can include more rewrite rules in mustBeBooleanMagicIn like > "rewrite instvar accessing" > context receiver class instVarNamesAndOffsetsDo: [ :n :o | > RBParseTreeRewriter new > replace: n with: ('ThisContext receiver instVarAt: ', o asString); > executeTree: methodNode. > ]. > "rewrite self sends" > RBParseTreeRewriter new > replace: 'self' with: 'ThisContext receiver'; > executeTree: methodNode. > > But I don't know if this works for all possible situations. Or if there are > better ways to do the rewriting. > > Remember the mirror methods: > thisContext object: o instVarAt: > which doesn't send to o, reaching directly into it. > > But what's the point of replacing "self" with "thisContext receiver"? The latter is potentially an extremely slow way of doing the former. The former won't create a context object in a method activation that doesn't need one (doesn't include a block), whereas the latter always will. But they will always yield the same result. > -- > curious, > Eliot > -- > best, > Eliot

Aug. 10, 2014

Re: [Pharo-dev] [Vm-dev] Re: mustBeBooleanMagicIn can crash the vm

by Eliot Miranda

Hi Nicolai, On Sun, Aug 10, 2014 at 9:39 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Hi Eliot, > > I am pretty sure this is not a vm issue :) > > The mustBeBooleanInMagic: creates a method on the fly and executes it with > the > a context as argument. > The "ThisContext" is not the "thisContext", but the argument of the > generated method. > > This is the bytecode of the generated method: > > 17 <00> pushRcvr: 0 > 18 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 22 to 23 > 22 <76> pushConstant: 1 > 23 <7D> blockReturn > 24 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 28 to 29 > 28 <75> pushConstant: 0 > 29 <7D> blockReturn > 30 <F0> send: ifTrue:ifFalse: > 31 <7C> returnTop > > The original method is > > foo > ^ notABool1 ifTrue:[1] ifFalse:[0] > > The generated method compiles this part > notABool1 ifTrue:[1] ifFalse:[0] > > to bytecode without the jumpFalse optimization. > The problem is that the receiver for the ifTrue:ifFalse send is accessed > through > pushRcvr:0, whereas the thisContext is not the context of the original > method anymore. > Ah, now I know what's going on. Thanks. I like this experiment very much. How do you extract the blocks from the method? Do you decompile or simply recompile from source or...? Have (any of) you looked at implementing the mustBeBooleanMagic by interpreting the bytecodes that already exist in the method via some specialized interpreter instead of compiling a method on the fly? Nicolai > > > 2014-08-10 17:34 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Hi Nicolai, >> >> please try and remember to invlude vm-dev when you see a VM issue... >> >> >> On Sun, Aug 10, 2014 at 7:34 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> There is a certain risk, that the mustBeBooleanMagicIn method rewrite >>> can crash the >>> vm >>> Issue 13805 <https://pharo.fogbugz.com/default.asp?13805> >>> >> >> Since you're using the Opal compiler ca you add the description of the >> bytecode (aCompiledMethod symbolic) to the issue? I'll try and take a look >> soon but want to be sure I'm debugging the relevant code. >> >> The receiver of the rewritten method is the "nonboolean" value receiving >>> the >>> ifTrue:ifFalse: message. But the rewritten method can include >>> instvar accessor and self sends of the original method. >>> >>> We can include more rewrite rules in mustBeBooleanMagicIn like >>> "rewrite instvar accessing" >>> context receiver class instVarNamesAndOffsetsDo: [ :n :o | >>> RBParseTreeRewriter new >>> replace: n with: ('ThisContext receiver instVarAt: ', o >>> asString); >>> executeTree: methodNode. >>> ]. >>> "rewrite self sends" >>> RBParseTreeRewriter new >>> replace: 'self' with: 'ThisContext receiver'; >>> executeTree: methodNode. >>> >>> But I don't know if this works for all possible situations. Or if there >>> are >>> better ways to do the rewriting. >>> >> >> Remember the mirror methods: >> thisContext object: o instVarAt: >> which doesn't send to o, reaching directly into it. >> >> But what's the point of replacing "self" with "thisContext receiver"? >> The latter is potentially an extremely slow way of doing the former. The >> former won't create a context object in a method activation that doesn't >> need one (doesn't include a block), whereas the latter always will. But >> they will always yield the same result. >> -- >> curious, >> Eliot >> > -- best, Eliot

Aug. 10, 2014

Updating the list of users

by Alexandre Bergel

Hi! We try to keep track of users of Roassal. It would be great to have your logo on http://objectprofile.com/Users.html So, if you are a Roassal (or Hapao, Roassal3d, Spy) user, let us know please! It helps building a strong community. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 10, 2014

Re: [Pharo-dev] [Vm-dev] Re: mustBeBooleanMagicIn can crash the vm

by Nicolai Hess

Hi Eliot, I am pretty sure this is not a vm issue :) The mustBeBooleanInMagic: creates a method on the fly and executes it with the a context as argument. The "ThisContext" is not the "thisContext", but the argument of the generated method. This is the bytecode of the generated method: 17 <00> pushRcvr: 0 18 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 22 to 23 22 <76> pushConstant: 1 23 <7D> blockReturn 24 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 28 to 29 28 <75> pushConstant: 0 29 <7D> blockReturn 30 <F0> send: ifTrue:ifFalse: 31 <7C> returnTop The original method is foo ^ notABool1 ifTrue:[1] ifFalse:[0] The generated method compiles this part notABool1 ifTrue:[1] ifFalse:[0] to bytecode without the jumpFalse optimization. The problem is that the receiver for the ifTrue:ifFalse send is accessed through pushRcvr:0, whereas the thisContext is not the context of the original method anymore. Nicolai 2014-08-10 17:34 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Nicolai, > > please try and remember to invlude vm-dev when you see a VM issue... > > > On Sun, Aug 10, 2014 at 7:34 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> There is a certain risk, that the mustBeBooleanMagicIn method rewrite can >> crash the >> vm >> Issue 13805 <https://pharo.fogbugz.com/default.asp?13805> >> > > Since you're using the Opal compiler ca you add the description of the > bytecode (aCompiledMethod symbolic) to the issue? I'll try and take a look > soon but want to be sure I'm debugging the relevant code. > > The receiver of the rewritten method is the "nonboolean" value receiving >> the >> ifTrue:ifFalse: message. But the rewritten method can include >> instvar accessor and self sends of the original method. >> >> We can include more rewrite rules in mustBeBooleanMagicIn like >> "rewrite instvar accessing" >> context receiver class instVarNamesAndOffsetsDo: [ :n :o | >> RBParseTreeRewriter new >> replace: n with: ('ThisContext receiver instVarAt: ', o asString); >> executeTree: methodNode. >> ]. >> "rewrite self sends" >> RBParseTreeRewriter new >> replace: 'self' with: 'ThisContext receiver'; >> executeTree: methodNode. >> >> But I don't know if this works for all possible situations. Or if there >> are >> better ways to do the rewriting. >> > > Remember the mirror methods: > thisContext object: o instVarAt: > which doesn't send to o, reaching directly into it. > > But what's the point of replacing "self" with "thisContext receiver"? The > latter is potentially an extremely slow way of doing the former. The > former won't create a context object in a method activation that doesn't > need one (doesn't include a block), whereas the latter always will. But > they will always yield the same result. > -- > curious, > Eliot > >

Aug. 10, 2014

Re: [Pharo-dev] mustBeBooleanMagicIn can crash the vm

by Camille Teruel

Hi Nicolai and Eliot, This is not a bug in the VM but in mustBeBooleanMagic:. The last line is "^ self withArgs: {context} executeMethod: method" whereas it should be "^ context receiver withArgs: {context} executeMethod: method". Thank you for reporting this, I committed the fix. Slice in inbox. Cheers, Camille On 10 aoÃ»t 2014, at 17:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Nicolai, > > please try and remember to invlude vm-dev when you see a VM issue... > > > On Sun, Aug 10, 2014 at 7:34 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > There is a certain risk, that the mustBeBooleanMagicIn method rewrite can crash the > vm > Issue 13805 > > Since you're using the Opal compiler ca you add the description of the bytecode (aCompiledMethod symbolic) to the issue? I'll try and take a look soon but want to be sure I'm debugging the relevant code. > > The receiver of the rewritten method is the "nonboolean" value receiving the > ifTrue:ifFalse: message. But the rewritten method can include > instvar accessor and self sends of the original method. > > We can include more rewrite rules in mustBeBooleanMagicIn like > "rewrite instvar accessing" > context receiver class instVarNamesAndOffsetsDo: [ :n :o | > RBParseTreeRewriter new > replace: n with: ('ThisContext receiver instVarAt: ', o asString); > executeTree: methodNode. > ]. > "rewrite self sends" > RBParseTreeRewriter new > replace: 'self' with: 'ThisContext receiver'; > executeTree: methodNode. > > But I don't know if this works for all possible situations. Or if there are > better ways to do the rewriting. > > Remember the mirror methods: > thisContext object: o instVarAt: > which doesn't send to o, reaching directly into it. > > But what's the point of replacing "self" with "thisContext receiver"? The latter is potentially an extremely slow way of doing the former. The former won't create a context object in a method activation that doesn't need one (doesn't include a block), whereas the latter always will. But they will always yield the same result. > -- > curious, > Eliot

Aug. 10, 2014

Re: [Pharo-dev] mustBeBooleanMagicIn can crash the vm

by Eliot Miranda

Hi Nicolai, please try and remember to invlude vm-dev when you see a VM issue... On Sun, Aug 10, 2014 at 7:34 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > There is a certain risk, that the mustBeBooleanMagicIn method rewrite can > crash the > vm > Issue 13805 <https://pharo.fogbugz.com/default.asp?13805> > Since you're using the Opal compiler ca you add the description of the bytecode (aCompiledMethod symbolic) to the issue? I'll try and take a look soon but want to be sure I'm debugging the relevant code. The receiver of the rewritten method is the "nonboolean" value receiving the > ifTrue:ifFalse: message. But the rewritten method can include > instvar accessor and self sends of the original method. > > We can include more rewrite rules in mustBeBooleanMagicIn like > "rewrite instvar accessing" > context receiver class instVarNamesAndOffsetsDo: [ :n :o | > RBParseTreeRewriter new > replace: n with: ('ThisContext receiver instVarAt: ', o asString); > executeTree: methodNode. > ]. > "rewrite self sends" > RBParseTreeRewriter new > replace: 'self' with: 'ThisContext receiver'; > executeTree: methodNode. > > But I don't know if this works for all possible situations. Or if there are > better ways to do the rewriting. > Remember the mirror methods: thisContext object: o instVarAt: which doesn't send to o, reaching directly into it. But what's the point of replacing "self" with "thisContext receiver"? The latter is potentially an extremely slow way of doing the former. The former won't create a context object in a method activation that doesn't need one (doesn't include a block), whereas the latter always will. But they will always yield the same result. -- curious, Eliot

Aug. 10, 2014

Re: [Pharo-dev] [Vm-dev] VM crash from triple 'Smalltalk garbageCollect' then forked Transcript stress test

by Eliot Miranda

Hi Ben, I'll try and take a look at this, but it'll really make things easier to do that if you create an image that runs the snipped from startup. e.g. evaluate the snipped preceded by Smalltalk snapshot: true andQuit: true Launch and if the VM doesn't crash rinse and repeat changing the snippet until the VM does crash on startup without user intervention. It's much easier to debug then. Then put that image & changes somewhere and email me the URL. On Sun, Aug 10, 2014 at 7:31 AM, Ben Coman <btc(a)openinworld.com> wrote: > > For Pharo I found the following snippet crashes the VM with fresh images. > > > Smalltalk garbageCollect. Smalltalk garbageCollect. Smalltalk > garbageCollect. > Transcript open. > [ Transcript crShow: ( > [ | string | > string := '-'. > 1 to: 2000 do: > [ :n | > string := string , '-', n printString. > Transcript show: string. > ]. > (Delay forMilliseconds: 10) wait. > ]) timeToRun. > ] fork. > > Over a dozen runs, this usually occurred on the second evaluation of that > snippet, and once each on the third and fourth evaluation of that snippet. > > > If there is only a single 'Smalltalk garbageCollect' rather than the > three, then the VM doesn't crash. > (Aside: I don't really know what use running it three times is, I just see > it down elsewhere.) > > I recorded four runs. > run1, run2, run3 were with... > $ curl get.pharo.org/alpha+vmLatest | bash > and run4 with... > $ curl get.pharo.org/30+vmLatest | bash > > Console logs and crash.dmp attached. > > --------- > All four runs show the same crash info at top... > --------- > Segmentation fault Sun Aug 10 21:17:09 2014 > C stack backtrace: > 0 Pharo 0x0004c0ef reportStackState + 159 > --------- > and bottom... > --------- > (Segmentation fault) > ./pharo-ui: line 11: 21593 Abort trap: 6 > "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" "$@" > --------- > but different stack dumps... > ---------run1 > Smalltalk stack dump: > 0xbffb68e4 M SmallInteger(Integer)>timesRepeat: 0x1=0 > 0xbffb6900 M CompositionScanner(CharacterScanner)>handleIndentation > 0x2300ced4: a(n) CompositionScanner > 0xbffb6920 M > CompositionScanner>composeFrom:inRectangle:firstLine:leftSide:rightSide: > 0x2300ced4: a(n) CompositionScanner > 0xbffb695c M TextComposer>composeEachRectangleIn: 0x21f2a340: a(n) > TextComposer > ---------run2 > Smalltalk stack dump: > 0xbffb7868 M BlockClosure>on:do: 0x21ff5a64: a(n) BlockClosure > 0xbffb7888 M BlockClosure>on:fork: 0x21ff5a64: a(n) BlockClosure > 0xbffb78a8 M WeakAnnouncementSubscription>deliver: 0x20e20260: a(n) > WeakAnnouncementSubscription > 0xbffb78cc M [] in SubscriptionRegistry>deliver:to:startingAt: 0x20e1e688: > a(n) SubscriptionRegistry > 0xbffb78ec M BlockClosure>ifCurtailed: 0x21ff59d4: a(n) BlockClosure > ---------run3 > 0xbfff204c M SmalltalkImage>garbageCollect 0x1fd577c4: a(n) SmalltalkImage > 0xbfff2064 M UndefinedObject>(nil) 0x1f500004: a(n) UndefinedObject > 0xbfff2094 I OpalCompiler>evaluate 0x220c1184: a(n) OpalCompiler > 0xbfff20c0 I SmalltalkEditor>evaluateSelectionAndDo: 0x20b2e930: a(n) > SmalltalkEditor > 0xbfff20e4 I SmalltalkEditor>evaluateSelection 0x20b2e930: a(n) > SmalltalkEditor > 0xbfff2104 I [] in PluggableTextMorph>doIt 0x20b18014: a(n) > PluggableTextMorph > ---------run4 > Smalltalk stack dump: > 0xbffb501c I SmalltalkImage>garbageCollect 0x1f969748: a(n) SmalltalkImage > 0xbffb5034 M UndefinedObject>(nil) 0x1f500004: a(n) UndefinedObject > 0xbffb5064 I OpalCompiler>evaluate 0x21eebda0: a(n) OpalCompiler > 0xbffb5090 I SmalltalkEditor>evaluateSelectionAndDo: 0x20970488: a(n) > SmalltalkEditor > 0xbffb50b4 I SmalltalkEditor>evaluateSelection 0x20970488: a(n) > SmalltalkEditor > 0xbffb50d4 I [] in PluggableTextMorph>doIt 0x209587f0: a(n) > PluggableTextMorph > --------- > > Maybe its Image code doing bad things rather than a VM bug, but I'm not > qualified to tell. Also I'm working on removing > ThreadSafeTranscriptPluggableTextMorph which wraps #update: and #drawOn: > with a mutex to avoid the same snippet causing a Red-Morph-Of-Death, so > maybe those changes will bypass the bug, but thought this report might be > generally useful if it flushed out some corner case. > > I'll copy any mail list discussion to > https://pharo.fogbugz.com/default.asp?13822. > cheers -ben > > -- best, Eliot

Aug. 10, 2014