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

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

by Levente Uzonyi

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. Levente > > > -- > best,Eliot > >

April 18, 2015

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

by Damien Cassou

Sean P. DeNigris <sean(a)clipperadams.com> writes: > Damien Cassou-2 wrote >> The Pharo_0.2.6.dmg seems to work fine for me > > <http://forum.world.st/file/n4820289/Screenshot_2015-04-17_14.png> I don't know why it doesn't work for you :-(. Are there other people with the same problem? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 18, 2015

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

by Ben Coman

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> wrote: > > > ----- Mail original ----- > > De: "Sean P. DeNigris" <sean(a)clipperadams.com> > > Ã: pharo-dev(a)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 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] PharoLauncher and Pharo 5.0

by Damien Cassou

Peter UhnÃ¡k <i.uhnak(a)gmail.com> writes: > Thanks! I was about to ask about this. :) > > Also could there be an option to reuse parameters provided to the > pharo(launcher) image? I always have to manually rewrite PhLimage>>launch: > to fix encoding. > ^OSProcess command: vmCommand , ' --textenc UTF-8 "' , imagePath, '"'. please try to implement it. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 18, 2015

Re: [Pharo-dev] PharoLauncher and Pharo 5.0

by Damien Cassou

Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> writes: > In settings, there used to be option to switch off categories of image > sources/templates, like hide Pharo 2 category, but this option seems to be > missing now. yes, I removed it because it was too costly to maintain. > And one more thing ... GUI has some weird colors (well, I think it is > actually missing colors). Screenshot: > https://monosnap.com/file/Fs6rfZTlstzqkKzyReRnPUVa28FVZe.png > However, this one is not today's change, because this morning I tried > updating launcher (to find out whether it supports Pharo 5 :) ) and colors > were already like this. I confirm and I don't know why. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 18, 2015

Re: [Pharo-dev] New Cog VMs available

by Chris Muller

> 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%. 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. This is like watching a gripping novel unfold! Congratulations ClÃ©ment for joining Eliot in Spur's engine room, and to Eliot for enjoying more company there, your elation is infectious..

April 18, 2015

Re: [Pharo-dev] New Cog VMs available

by David T. Lewis

On Fri, Apr 17, 2015 at 06:46:19PM -0700, 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! The project list at http://www.mirandabanda.org/cogblog/cog-projects/ makes for really good reading in its own right, even if it makes me feel just a bit badly about my own lack of progress on that last item in the list. But we will get there :-) Kudos to Cl??ment, Tim, Ryan and Eliot for the initiative and teamwork! Dave

April 18, 2015

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

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! -- best, Eliot

April 18, 2015

Re: [Pharo-dev] New Cog VMs available

by ClÃ©ment Bera

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 :-) > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/New-Cog-VMs-available-tp4820107p4820113.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 18, 2015

Re: [Pharo-dev] New Cog VMs available

by ClÃ©ment Bera

2015-04-17 13:35 GMT-07:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Fri, Apr 17, 2015 at 3:41 AM, stepharo <stepharo(a)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