April 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New Cog VMs available

by stepharo

>>> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3311/. >>> >>> These should fix the regression introduced by the map changes in >>> 3308. They certainly fix the two crashes I've looked at, one an >>> update of a squeak trunk image and the other the startup of >>> recent Newspeak images. Apologies for the inconvenience. >> >> Well, this is embarrassing as usual but I'm still seeing crashes >> in the image update. So I'll have to look deeper. At least the >> Newspeak fix was real, but it didn't fix everything. > > :) > Hi eliot > How can we help? > Would it make sense to have some more ci jobs for testing the VM? > > > Yes, that always helps. But we have to accept that that means > a) these CI jobs will detect failures caused by regressions etc > b) we need to mark builds as "bleeding edge" "last known good" etc, > and set these pointers > > b) I have yet to set up. > > But yesterday and today a wonderful thing has happened. ClÃ©ment has > understood the core optimization and code generation structures in the > JIT as well as I do and is now both improving the code quality and > implementing more aggressive optimizations. That's cool. > This is /so/ satisfying. You know how good ClÃ©ment is. His input is > so strong. I am /very/ happy. For example, ClÃ©ment is currently > modifying #== in the Spur JIT so that the code checks for forwarders > only if #== is false, and that if #== is false and either object is a > forwarder, it/them is/are followed and the #== retried. This should > speed up #== by 50%. It won't make much difference at the macro level > but this is a non-trivial optimization to write and so now we have two > people who really understand the core optimizing JIT and I can now > happily run in front of a bus. I'm happy too. BTW Kevin is making progress on the decompiler. So we have young guys learning around too. > > > Stef > >>> >>> >>> CogVM binaries as per VMMaker.oscog-eem.1204/r3311 >>> >>> Cogits: >>> >>> Fix regression in map machinery due to adding >>> AnnotationExtension scheme. >>> findMapLocationForMcpc:inMethod: must not be confused by >>> IsDisplacementX2N >>> bytes. This is likely the cause of the recent crashes with >>> r3308 and earlier. >>> >>> Introduce marryFrameCopiesTemps and use it to >>> not copy temps in Spur context creation trampolines. >>> >>> Change initial usage counts to keep more recently jitted methods >>> around for >>> longer, and do *not* throw away PICs in >>> freeOlderMethodsForCompaction, so that >>> there's a better chance of Sista finding send and branch data >>> for the tripping >>> method. >>> >>> extendedPushBytecode /does/ need a frame. >>> >>> Don't save the header in a scratch register unless >>> it is useful to do so in the Spur at:[put:] primitives. >>> >>> Fix slip in genGetNumBytesOf:into:. And notice that >>> genGetFormatOf:into:baseHeaderIntoScratch: et al can use byte access >>> to get at format, as intended in the Spur header design. >>> >>> Fix unlinking dynamic super sends. >>> >>> Reduce false positives in access control violation reporting by >>> marking the >>> super send we actually use as privileged. Remove unused Newspeak >>> bytecodes. >>> >>> Internal: >>> >>> Fix code generation bug surfaced by inline primitives. On x86 >>> movb N(%reg),%rl >>> can only store into al, bl, cl & dl, whereas movzbl can store >>> into any reg. On >>> ARM move byte also zero-extends. So change definition of >>> MoveMbrR to always >>> zero-extend, use movzbl on x86 and remove all the MoveCq: 0 R: >>> used to zero the >>> bits of the target of a MoveMb:r:R:. And now that we have >>> genGetNumSlotsOf:into:, use it. >>> >>> Fix a slip in genTrinaryInlinePrimitive:, meet constraint that >>> the target must >>> be in ReceiverResultReg, and do a better job of register >>> allocation there-in. >>> >>> Do dead code elimination for the branch following an inlined >>> comparison (this >>> is done in genBinaryInlineComparison:opFalse:destReg: copying >>> the scheme in >>> genSpecialSelectorEqualsEquals). >>> >>> Do register allocation in the right place in >>> genUnaryInlinePrimitive:. >>> >>> Fix overflow slot access in genGetNumSlotsOf:into: et al. >>> >>> Fix several slips in inline primitive generation: >>> Object>>at:put: needs to >>> include a store check. Some register allocation code was >>> wrong. Some results >>> needed converting to SmallIntegers and recording results as >>> pushed on the sim >>> stack. >>> >>> Change callPrimitiveBytecode to genCallPrimitiveBytecode in the >>> Cogit. >>> remove the misnomer genConvertIntegerToSmallIntegerInScratchReg: >>> >>> Type of AbstractInstruction opcode must be unsigned now that we have >>> more than 128 opcodes (XCHGRR pushed things over the top). >>> >>> Lay the groundwork for 32-bit intra-zone jumps and calls on ARM >>> by introducing >>> CallFull and JumpFull (and rewrites thereof) that are expected >>> to span the full >>> address space, leaving Call/JumpLong to span merely the 16mb >>> code zone. On x86 >>> CallFull and JumpFull simply default to Call/JumpLong. >>> >>> Replace bytecode trapIfNotInstanceOf by jumpIfNotInstanceOfOrPop. >>> >>> Rewrote the JIT logic for traps to be able to write trap >>> trampolines calls at >>> the end of the cogMethod. >>> >>> Refactor the slot store and store check machinery to take an >>> inFrame: argument >>> and hence deal with the store check in genInnerPrimitiveAtPut: >>> on ARM. >>> >>> Fix limitation with MoveRXbrR; can only do movb from >>> %al through %dl, so swap with %eax around movb. >>> >>> Fix mistake with genGetNumBytesOf:into: by refactoring >>> genGetFormatOf:into:baseHeaderIntoScratch: into >>> genGetBits:ofFormatByteOf:into:baseHeaderIntoScratch: >>> and hence fetching and subtracting only odd bits of format. >>> >>> Correct the in-line primitive SmallInteger comparisons; CmpXR is >>> confusing ;-) >>> >>> Fix var op var unsafe byte at:. Result must be converted to >>> SmallInteger. >>> >>> Correct the generated Slang for the new register allocation code >>> by adding a >>> read-before-written pass to C generation that initializes variables >>> read-before-written with 0 (the C equivalent of nil). >>> >>> fix a bug where sometimes register allocation was marking >>> ReceiverResultReg as >>> dead whereas it was still alive. >>> >>> Added some abstraction over register allocation. This is now >>> used in inline >>> primitives. >>> >> > > > > > -- > best, > Eliot

April 18, 2015

Re: [Pharo-dev] New Cog VMs available

by stepharo

Clement you will have to explain that to mere mortals :) BTW I was thinking that you should get in touch with Nicolai Hesse about MT :) Stef Le 18/4/15 02:15, ClÃ©ment Bera a Ã©crit : > > > 2015-04-17 13:35 GMT-07:00 Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>>: > > > > On Fri, Apr 17, 2015 at 3:41 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > >>> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3311/. >>> >>> These should fix the regression introduced by the map >>> changes in 3308. They certainly fix the two crashes I've >>> looked at, one an update of a squeak trunk image and the >>> other the startup of recent Newspeak images. Apologies for >>> the inconvenience. >> >> Well, this is embarrassing as usual but I'm still seeing >> crashes in the image update. So I'll have to look deeper. At >> least the Newspeak fix was real, but it didn't fix everything. > > :) > Hi eliot > How can we help? > Would it make sense to have some more ci jobs for testing the VM? > > > Yes, that always helps. But we have to accept that that means > a) these CI jobs will detect failures caused by regressions etc > b) we need to mark builds as "bleeding edge" "last known good" > etc, and set these pointers > > b) I have yet to set up. > > But yesterday and today a wonderful thing has happened. ClÃ©ment > has understood the core optimization and code generation > structures in the JIT as well as I do and is now both improving > the code quality and implementing more aggressive optimizations. > This is /so/ satisfying. You know how good ClÃ©ment is. His input > is so strong. I am /very/ happy. For example, ClÃ©ment is > currently modifying #== in the Spur JIT so that the code checks > for forwarders only if #== is false, and that if #== is false and > either object is a forwarder, it/them is/are followed and the #== > retried. This should speed up #== by 50%. > > > I think you made a typo. > > * This should speed up #== in the case where the answer was true, > which theoretically is in 50% of the cases, but in practice we've not > profiled it. > > It won't make much difference at the macro level but this is a > non-trivial optimization to write and so now we have two people > who really understand the core optimizing JIT and I can now > happily run in front of a bus. > > > It will make a difference on some benchmarks where we saw the overhead > of #== due to forwarding pointers checks. > > And Ryan has a really good understanding too. I really enjoy the > abstraction he made over the send logic. > And Tim has the ARM backend almost working too (it's a week of work to > have it working as far as I understood). > > > > Stef > >>> >>> >>> CogVM binaries as per VMMaker.oscog-eem.1204/r3311 >>> >>> Cogits: >>> >>> Fix regression in map machinery due to adding >>> AnnotationExtension scheme. >>> findMapLocationForMcpc:inMethod: must not be confused by >>> IsDisplacementX2N >>> bytes. This is likely the cause of the recent crashes with >>> r3308 and earlier. >>> >>> Introduce marryFrameCopiesTemps and use it to >>> not copy temps in Spur context creation trampolines. >>> >>> Change initial usage counts to keep more recently jitted >>> methods around for >>> longer, and do *not* throw away PICs in >>> freeOlderMethodsForCompaction, so that >>> there's a better chance of Sista finding send and branch >>> data for the tripping >>> method. >>> >>> extendedPushBytecode /does/ need a frame. >>> >>> Don't save the header in a scratch register unless >>> it is useful to do so in the Spur at:[put:] primitives. >>> >>> Fix slip in genGetNumBytesOf:into:. And notice that >>> genGetFormatOf:into:baseHeaderIntoScratch: et al can use >>> byte access >>> to get at format, as intended in the Spur header design. >>> >>> Fix unlinking dynamic super sends. >>> >>> Reduce false positives in access control violation reporting >>> by marking the >>> super send we actually use as privileged. Remove unused >>> Newspeak bytecodes. >>> >>> Internal: >>> >>> Fix code generation bug surfaced by inline primitives. On >>> x86 movb N(%reg),%rl >>> can only store into al, bl, cl & dl, whereas movzbl can >>> store into any reg. On >>> ARM move byte also zero-extends. So change definition of >>> MoveMbrR to always >>> zero-extend, use movzbl on x86 and remove all the MoveCq: 0 >>> R: used to zero the >>> bits of the target of a MoveMb:r:R:. And now that we have >>> genGetNumSlotsOf:into:, use it. >>> >>> Fix a slip in genTrinaryInlinePrimitive:, meet constraint >>> that the target must >>> be in ReceiverResultReg, and do a better job of register >>> allocation there-in. >>> >>> Do dead code elimination for the branch following an inlined >>> comparison (this >>> is done in genBinaryInlineComparison:opFalse:destReg: >>> copying the scheme in >>> genSpecialSelectorEqualsEquals). >>> >>> Do register allocation in the right place in >>> genUnaryInlinePrimitive:. >>> >>> Fix overflow slot access in genGetNumSlotsOf:into: et al. >>> >>> Fix several slips in inline primitive generation: >>> Object>>at:put: needs to >>> include a store check. Some register allocation code was >>> wrong. Some results >>> needed converting to SmallIntegers and recording results as >>> pushed on the sim >>> stack. >>> >>> Change callPrimitiveBytecode to genCallPrimitiveBytecode in >>> the Cogit. >>> remove the misnomer genConvertIntegerToSmallIntegerInScratchReg: >>> >>> Type of AbstractInstruction opcode must be unsigned now that >>> we have >>> more than 128 opcodes (XCHGRR pushed things over the top). >>> >>> Lay the groundwork for 32-bit intra-zone jumps and calls on >>> ARM by introducing >>> CallFull and JumpFull (and rewrites thereof) that are >>> expected to span the full >>> address space, leaving Call/JumpLong to span merely the 16mb >>> code zone. On x86 >>> CallFull and JumpFull simply default to Call/JumpLong. >>> >>> Replace bytecode trapIfNotInstanceOf by >>> jumpIfNotInstanceOfOrPop. >>> >>> Rewrote the JIT logic for traps to be able to write trap >>> trampolines calls at >>> the end of the cogMethod. >>> >>> Refactor the slot store and store check machinery to take an >>> inFrame: argument >>> and hence deal with the store check in >>> genInnerPrimitiveAtPut: on ARM. >>> >>> Fix limitation with MoveRXbrR; can only do movb from >>> %al through %dl, so swap with %eax around movb. >>> >>> Fix mistake with genGetNumBytesOf:into: by refactoring >>> genGetFormatOf:into:baseHeaderIntoScratch: into >>> genGetBits:ofFormatByteOf:into:baseHeaderIntoScratch: >>> and hence fetching and subtracting only odd bits of format. >>> >>> Correct the in-line primitive SmallInteger comparisons; >>> CmpXR is confusing ;-) >>> >>> Fix var op var unsafe byte at:. Result must be converted to >>> SmallInteger. >>> >>> Correct the generated Slang for the new register allocation >>> code by adding a >>> read-before-written pass to C generation that initializes >>> variables >>> read-before-written with 0 (the C equivalent of nil). >>> >>> fix a bug where sometimes register allocation was marking >>> ReceiverResultReg as >>> dead whereas it was still alive. >>> >>> Added some abstraction over register allocation. This is now >>> used in inline >>> primitives. >>> >> > > > > > -- > best, > Eliot > >

April 18, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50002 Home: https://github.com/pharo-project/pharo-core

April 18, 2015

[pharo-project/pharo-core] 840599: 50002

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 840599b9caff31c85c3160582e3c388d4ff5b239 https://github.com/pharo-project/pharo-core/commit/840599b9caff31c85c316058… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-18 (Sat, 18 Apr 2015) Changed paths: M FreeType.package/FreeTypeFont.class/instance/displaying/displayLineGlyphOn_from_to_.st M FreeType.package/FreeTypeFont.class/instance/displaying/displayString_on_from_to_at_kern_baselineY_.st M FreeType.package/FreeTypeFont.class/instance/glyph lookup/glyphOf_destDepth_colorValue_subpixelPosition_.st M FreeType.package/FreeTypeSettings.class/instance/accessing/subPixelAntiAliasing.st A FreeType.package/FreeTypeSettings.class/instance/accessing/useSubPixelAntiAliasing.st M FreeType.package/extension/BitBlt/instance/installFreeTypeFont_foregroundColor_backgroundColor_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script610.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script611.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50001.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50002.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50002 15358 FreeTypeFont uses the wrong combination rule if subPixelAntiAliasing is disabled https://pharo.fogbugz.com/f/cases/15358 http://files.pharo.org/image/50/50002.zip

April 18, 2015

Re: [Pharo-dev] Launcher Mac CI -> Broken Executable

by stepharo

Indeed launcher is a better name. Le 18/4/15 06:56, Ben Coman a Ã©crit : > > This is where calling PharoLauncher "Pharo" is confusing. There is > Pharo 0.2.4 and also Pharo 4.0. What is a newcomer to think? > Cheers -ben > > On 17/04/2015 11:58 pm, "Damien Cassou" <damien.cassou(a)inria.fr > <mailto:damien.cassou@inria.fr>> wrote: > > > > ----- Mail original ----- > > De: "Sean P. DeNigris" <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>> > > Ã: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > > EnvoyÃ©: Vendredi 17 Avril 2015 07:35:31 > > Objet: Re: [Pharo-dev] Launcher Mac CI -> Broken Executable > > > > Sean P. DeNigris wrote > > > "Pharo" is damaged and can't be opened. You should move it to > the Trash. > > > > All broken back to build #24 from Feb 25th. It was very tedious > to find that > > out, since the builds all claim to produce Pharo_0.2.4 > > The Pharo_0.2.6.dmg seems to work fine for me. It looks like > files.pharo.org <http://files.pharo.org> does not contain the file > yet. Please use: > https://ci.inria.fr/pharo/view/all/job/Launcher-Mac/44/artifact/Pharo_0.2.6… >

April 18, 2015

Re: [Pharo-dev] NativeBoost / Callbacks and Multithreading

by stepharo

Nicolai If I remember igor wanted to manage the threaded code at the level of NB by creating all the machinery there. Now talking with Eliot and clement, they have a design of Threaded FFI that is definitively something that we need people to help on. Clement told me that the design was not complex and inspired from a python one. (but I may be wrong). Clement? Stef > > I've tried to build a pharovm with multithread support. I changed the > config in the > pharo generator.image to use the cogmt config and was able to build a vm. > But this vm crashes on startup. (windows7) > > Is this the right way and did anyone got this to work (windows or linux)? > > And can this work to make NB callbacks working for multithreaded > libraries. > > (I made some simple bindings for the gstreamer lib with NB, this works > for simple calls (create element/change state). But I guess this won't > work > for any gstreamer function that requests a callback that may b e > called from > a different thread) > > Would this be the right way to do: > - build a vm with MT support > - guard the NB callback entry/leave code with the ownVM()/disownVM() call. > > Or is there more to do. > > Thanks in advance > > > nicolai > >

April 18, 2015

Bloc CI?

by stepharo

hi guys I would like to update the CI to point to the new location. What do you think? Stef

April 18, 2015

Re: [Pharo-dev] Rubric and Bloc are now in PharoExtras

by stepharo

April 18, 2015

Re: [Pharo-dev] [squeak-dev] Re: New Cog VMs available

by ClÃ©ment Bera

2015-04-17 22:00 GMT-07:00 Levente Uzonyi <leves(a)elte.hu>: > On Fri, 17 Apr 2015, Eliot Miranda wrote: > > >> >> On Fri, Apr 17, 2015 at 5:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> >> >> 2015-04-16 17:16 GMT-07:00 Sean P. DeNigris <sean(a)clipperadams.com >> >: >> Eliot Miranda-2 wrote >> > ... >> >> Wow! That seems like a /lot/ of fixes... thanks :) >> >> >> This past few weeks we were 4 to commit regularly on the JIT (Tim, Ryan, >> Eliot and I) so there are more fixes than when Eliot is working alone :-) >> >> >> Finally we have a team working on it. Come join us!! There's /lots/ to >> work on. See http://www.mirandabanda.org/cogblog/cog-projects/ & >> http://www.mirandabanda.org/cogblog/collaborators/. It is challenging, >> useful and FUN! >> > > "- a solution to the problem of free space in segments containing pinned > objects at snapshot time" > > My naive approach would be to separate pinned objects from non-pinned > objects. Whenever you pin an object, it's moved to a "pinned" segment - > which is a segment with only pinned objects - and vica versa. > And that could be done with a forwarding object so it would be very fast... That could make sense. > > Levente > > >> >> -- >> best,Eliot >> >>

April 18, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo 4.0 is released!

by volkert

Coooool! Yes, spread the Word. Is there a cool promotion flyer / booklet for Pharo? I found this here: http://files.pharo.org/media/flyer-cheat-sheet.pdf. Not really attractive ... Is there something better? BW, Volkert Am 16.04.2015 um 11:29 schrieb Esteban Lorenzano: > Please spread widely. > Sorry for multiple posts. >

April 18, 2015