- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

Hi. 2016-01-04 19:19 GMT+01:00 Igor Stasenko <siguctua(a)gmail.com>: > It heavily depends on data structure you using what kind of > synchronization mechanism is more efficient than another. > For instance AtomicQueue implementation is one that falls in such category > 'many readers, but only single writer'. But it's not using semaphores to > synchronise access to it. > Can you explain deeply what problem with AtomicQueue in 'many readers, but only single writer'?

Jan. 5, 2016

Reverted changes in Monticello ?

by Thierry Goubier

Hi all, I had an error with the metadata-less mode of gitfiletree, and I discovered that a fix[1], integrated in 50470, was reverted sometime afterwards. And when looking a bit more, 50510 has MonticelloFileTree-Core-TheIntegrator.134 while the latest in main is MonticelloFileTree-Core-TheIntegrator.193 (with not a few fixes). Anybody knows what is happening? Thierry [1] https://pharo.fogbugz.com/f/cases/17125/Metadata-less-compatibility-with-Fi…

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

Hi 2016-01-04 18:55 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > Hi Denis, > > How does your ReadWriteLock compare to Monitor? I was under the impression > that what you describe could be done with a Monitor. Monitor is different synchronisation mechanism. It can be used to implement ReadWriteLock. But It looks like more expensive solution. After look at Pharo implementation of Monitor I realise that it #critical: method not takes into account issue described in Semaphore>>critical:. I will ask about it on separate thread.

Jan. 5, 2016

Re: [Pharo-dev] [Vm-dev] Repeatable VM crash

by Esteban Lorenzano

> On 04 Jan 2016, at 21:22, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Sun, Dec 7, 2014 at 3:27 PM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > Hi Mariano, > > On Dec 7, 2014, at 10:21 AM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > >> >> >> On Sun, Dec 7, 2014 at 3:09 PM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> Hi Hilaire, >> >> >> On Dec 7, 2014, at 12:35 AM, Hilaire <hilaire(a)drgeo.eu <mailto:hilaire@drgeo.eu>> wrote: >> >> > I download this one >> > http://www.mirandabanda.org/files/Cog/VM/VM.r3164/coglinux-14.48.3164.tgz <http://www.mirandabanda.org/files/Cog/VM/VM.r3164/coglinux-14.48.3164.tgz> >> > >> > and the crash is still there. Attached crash dump. >> >> different bugs. The 3164 VMs fix a 32-bit Spur bug. Your image is showing a bug in Cog that looks to be to do with the decompression primitive. I haven't had time to look at it deeply yet but can see it and should be able to fix it soon. >> >> You mean GZip stuff? Because I have found a similar issue years ago: http://forum.world.st/Re-Pharo-project-GZipWriteStream-crashing-my-VM-when-… <http://forum.world.st/Re-Pharo-project-GZipWriteStream-crashing-my-VM-when-…> > No. That bug got fixed recently. This is a bug in the custom huffman-ciding bitmap decompression routine (selector begins with "decompress") that's compiled to a primitive. > > > > Hi, > > It seems Stephan is seeing this bug again. > Eliot, is there a chance that the fix was not finally integrated or something? vm build is at least 1 month old (spur one). Cog vm is at least 6 months old (yet some stuff has been integrated into it, but not much). vm development is moving to spur branch so changes will be there (and not old cog branch) but to resume vm build we need to fix a bug in opal compiler (in spur context): https://pharo.fogbugz.com/f/cases/17251 <https://pharo.fogbugz.com/f/cases/17251> Soâ¦ probably, that bug fix is not present yet in the vm (I cannot be sure, but probably) Esteban > > > >> >> >> > >> > Thanks >> > >> > Hilaire >> > >> > Le 06/12/2014 22:57, Eliot Miranda a Ã©crit : >> >> Hi Esteban, >> >> >> >> plausibly the fix to the latest VM might fix your crash. You might >> >> test? Fingers crossed. >> >> >> >> On Fri, Dec 5, 2014 at 11:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> >> >> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: >> >> >> >> yes, but the first step is to be sure you have the latest vm version :) >> >> >> >> Esteban >> > >> > >> > -- >> > Dr. Geo - http://drgeo.eu <http://drgeo.eu/> >> > iStoa - http://istoa.drgeo.eu <http://istoa.drgeo.eu/> >> > <crash.dmp> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Jan. 5, 2016

Re: [Pharo-dev] Some test where Spur more slow than Cog

by ClÃ©ment Bera

I could reproduce with Squeak 5 and Squeak 4.6 so I was able to use the VM profiler. I used: | prototype | prototype := BorderedMorph new. 10000 timesRepeat: [prototype veryDeepCopy] The profiler ran for ~0.8 second. Maybe you can have more accurate result with longer bench but it takes already a while to display results. *In Spur:* 1044 samples in the VM (1057 samples in the entire program) 98.77% of total 754 samples in generated vm code 72.22% of entire vm (71.33% of total) 290 samples in vanilla vm code 27.78% of entire vm (27.44% of total) % of generated vm code (% of total) (samples) (cumulative) 37.67% (26.87%) Dictionary>>associationsDo: (284) (37.67%) 30.37% (21.67%) Object>>at: (229) (68.04%) 3.18% ( 2.27%) WeakKeyDictionary>>associationsDo: (24) (71.22%) 2.12% ( 1.51%) MethodDictionary>>scanFor: (16) (73.34%) 1.59% ( 1.14%) SmallInteger>>\\ (12) (74.93%) % of vanilla vm code (% of total) (samples) (cumulative) 58.62% (16.08%) scavengeReferentsOf (170) (58.62%) 24.48% ( 6.72%) instantiateClassindexableSize (71) (83.10%) 2.76% ( 0.76%) copyAndForward (8) (85.86%) 2.07% ( 0.57%) doScavenge (6) (87.93%) 2.07% ( 0.57%) lookupOrdinaryNoMNUEtcInClass (6) (90.00%) 13 samples in the rest 1.23% of total % of rest (% of total) (samples) (cumulative) 53.85% ( 0.66%) SCDynamicStoreCreate (7) (53.85%) 46.15% ( 0.57%) _platform_memmove$VARIANT$sse42 (6) (100.0%) 46.15% ( 0.57%) OSAtomicAdd32Barrier (6) (146.15%) **GCs** full 0 totalling 0ms (0% elapsed time) scavenges 258 totalling 151ms (18.97% elapsed time), avg 0.585ms *In SqueakV3:* 1189 samples in the VM (1196 samples in the entire program) 99.41% of total 998 samples in generated vm code 83.94% of entire vm (83.44% of total) 191 samples in vanilla vm code 16.06% of entire vm (15.97% of total) % of generated vm code (% of total) (samples) (cumulative) 43.19% (36.04%) Object>>at: (431) (43.19%) 35.07% (29.26%) Dictionary>>associationsDo: (350) (78.26%) 1.90% ( 1.59%) WeakKeyDictionary>>associationsDo: (19) (80.16%) 1.30% ( 1.09%) Object>>veryDeepCopyWith: (13) (81.46%) 1.20% ( 1.00%) BlockClosure>>value (12) (82.67%) % of vanilla vm code (% of total) (samples) (cumulative) 30.37% ( 4.85%) instantiateClassindexableSize (58) (30.37%) 13.61% ( 2.17%) incrementalGC (26) (43.98%) 9.42% ( 1.51%) markAndTrace (18) (53.40%) 8.38% ( 1.34%) marryFrameSP (16) (61.78%) 6.81% ( 1.09%) eeInstantiateSmallClassnumSlots (13) (68.59%) 5.24% ( 0.84%) createClosureNumArgsnumCopiedstartpc (10) (73.82%) 4.71% ( 0.75%) mapPointersInObjectsFromto (9) (78.53%) **GCs** full 0 totalling 0ms (0% elapsed time) incr 270 totalling 46ms (5.094% elapsed time), avg 0.17ms *Conclusion ?* It feels that the main issue is with the scavenges that take overall more time in Spur in this case. Especially, the method scavengeReferentsOf seems to be guilty and may be worth looking at. There are other details, like now a little bit of execution time seems to be used to allocate new memory segments and associationsDo: looks slower, likely because of == and forwarders, but this is not as important. What do you think Eliot ? 2015-12-19 11:06 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi > > 2015-12-19 4:18 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> and used in some copying code to access indexable fields. Chris Muller >> found this in some of his Magma code and so we added a pair of new >> primitives, primitiveSlotAt and primitiveSlotAtPut that access any slot >> within the sequence of named followed by indexable inst vars, avoiding the >> primitive failure. So in Squeak Spur instVarAt: now reads: >> >> instVarAt: index >> "Primitive. Answer a fixed variable in an object. The numbering of the >> variables >> corresponds to the named instance variables, followed by the indexed >> instance >> variables. Fail if the index is not an Integer or is not the index of a >> fixed variable. >> Essential. See Object documentation whatIsAPrimitive." >> >> <primitive: 173 error: ec> >> self primitiveFailed >> > > Same code used in Pharo too. > > I try same test on latest squeak images: > > Cog: '10,100 per second. 98.8 microseconds per run.' > Spur: '7,610 per second. 131 microseconds per run.' >

Jan. 5, 2016

Re: [Pharo-dev] Repeatable VM crash

by Mariano Martinez Peck

On Sun, Dec 7, 2014 at 3:27 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Mariano, > > On Dec 7, 2014, at 10:21 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > On Sun, Dec 7, 2014 at 3:09 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Hilaire, >> >> >> On Dec 7, 2014, at 12:35 AM, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> > I download this one >> > >> http://www.mirandabanda.org/files/Cog/VM/VM.r3164/coglinux-14.48.3164.tgz >> > >> > and the crash is still there. Attached crash dump. >> >> different bugs. The 3164 VMs fix a 32-bit Spur bug. Your image is >> showing a bug in Cog that looks to be to do with the decompression >> primitive. I haven't had time to look at it deeply yet but can see it and >> should be able to fix it soon. >> > > You mean GZip stuff? Because I have found a similar issue years ago: > http://forum.world.st/Re-Pharo-project-GZipWriteStream-crashing-my-VM-when-… > > > No. That bug got fixed recently. This is a bug in the custom > huffman-ciding bitmap decompression routine (selector begins with > "decompress") that's compiled to a primitive. > > Hi, It seems Stephan is seeing this bug again. Eliot, is there a chance that the fix was not finally integrated or something? > > >> >> > >> > Thanks >> > >> > Hilaire >> > >> > Le 06/12/2014 22:57, Eliot Miranda a Ã©crit : >> >> Hi Esteban, >> >> >> >> plausibly the fix to the latest VM might fix your crash. You might >> >> test? Fingers crossed. >> >> >> >> On Fri, Dec 5, 2014 at 11:26 PM, Esteban Lorenzano < >> estebanlm(a)gmail.com >> >> <mailto:estebanlm@gmail.com>> wrote: >> >> >> >> yes, but the first step is to be sure you have the latest vm >> version :) >> >> >> >> Esteban >> > >> > >> > -- >> > Dr. Geo - http://drgeo.eu >> > iStoa - http://istoa.drgeo.eu >> > <crash.dmp> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Jan. 4, 2016

Re: [Pharo-dev] do you know we have an issue tracker? (rant)

by Torsten Bergmann

You wanted to rebuild the Windows Spur VM due to some missing changes: https://pharo.fogbugz.com/f/cases/17289/Spur-VM-breaks-CTRL-keys-on-Windows The one you provided on 14.12.2015 is without correct CTRL key handling and therefore not very usable. Nicolai provided also some info's in the issue. While compiling you can review https://pharo.fogbugz.com/f/cases/17253 ;) Thanks T. > Gesendet: Montag, 04. Januar 2016 um 19:13 Uhr > Von: "Johan Fabry" <jfabry(a)dcc.uchile.cl> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] do you know we have an issue tracker? (rant) > > > Just to be sure, did you get notified for this one? https://pharo.fogbugz.com/f/cases/17309/Roassal2-in-Pharo-5-produces-a-segf… > > > On Jan 4, 2016, at 11:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > Hi guys, > > > > Soâ¦ last two weeks I was first in Togo with Stef and after taking holidays for the end of the year. > > During that time some bugs on new FFI emerged and were talked in this listâ¦ > > > > Today I came back to work and I wanted to walk through the issues to priorize and start work on fixing themâ¦ and no reports on the issue tracker :( > > > > So Iâm forced to do email-archeology to dig up the problemsâ¦ or just ignore them until a report arrives. > > > > What is not in the issue tracker does not exist: PLEASE REPORT YOUR ISSUES. > > > > thanks, > > Esteban > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > > >

Jan. 4, 2016

Re: [Pharo-dev] do you know we have an issue tracker? (rant)

by Dimitris Chloupis

ninja coders beg for less bug reports , technomages beg for more :D On Mon, Jan 4, 2016 at 4:35 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi guys, > > Soâ¦ last two weeks I was first in Togo with Stef and after taking holidays > for the end of the year. > During that time some bugs on new FFI emerged and were talked in this listâ¦ > > Today I came back to work and I wanted to walk through the issues to > priorize and start work on fixing themâ¦ and no reports on the issue tracker > :( > > So Iâm forced to do email-archeology to dig up the problemsâ¦ or just > ignore them until a report arrives. > > What is not in the issue tracker does not exist: PLEASE REPORT YOUR ISSUES. > > thanks, > Esteban >

Jan. 4, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Igor Stasenko

It heavily depends on data structure you using what kind of synchronization mechanism is more efficient than another. For instance AtomicQueue implementation is one that falls in such category 'many readers, but only single writer'. But it's not using semaphores to synchronise access to it. On 4 January 2016 at 20:06, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > If I understand correctly: > - the Monitor only offer one kind of critical section that typically > affects everyone equally, > - while with the new ReadWriteLock, the readers will be blocked only if a > writer will acquire the writer critical section. > > Cheers, > Doru > > > > On Jan 4, 2016, at 7:55 PM, Max Leske <maxleske(a)gmail.com> wrote: > > > > Hi Denis, > > > > How does your ReadWriteLock compare to Monitor? I was under the > impression that what you describe could be done with a Monitor. > > > > Cheers, > > Max > > > > > >> On 04 Jan 2016, at 18:39, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> > >> Hi. > >> > >> I implemented small package ReadWriteLock > http://smalltalkhub.com/mc/Pharo/ReadWriteLock/main. > >> > >> Gofer it > >> smalltalkhubUser: 'Pharo' project: 'ReadWriteLock'; > >> configurationOf: 'ReadWriteLock'; > >> loadStable > >> > >> It is reentral read write lock which described in > >> https://en.wikipedia.org/wiki/Readersâwriter_lock. From the article: > >> > >> An ReadWriteLock allows concurrent access for read-only operations, > while write operations require exclusive access. This means that multiple > threads can read the data in parallel but an exclusive lock is needed for > writing or modifying data. When a writer is writing the data, all other > writers or readers will be blocked until the writer is finished writing. > >> > >> Public API and Key Messages > >> > >> - lock := ReadWriteLock new > >> - lock criticalRead: aBlock > >> - lock criticalWrite: aBlock > >> > >> Implementation based on two semaphores and readers counter. > >> > >> Main difficulty is carefully handle process termination during > execution of critical sections. This problem described in > Semaphore>>critical: comment. Same approach is used here. But > synchronisation logic around two semaphores for reading and writing > complicates things very much. No simple way to decompose logic on multiple > methods because information about process interruption become hidden. > >> From the Semaphore comment: > >> The main trick is assignment right before we go into the wait primitive > (which is not a real send and therefore not interruptable either). So after > we can check that waiting is happen or not. > >> > >> Tests are implemented only for lock scenarios. No tests for described > termination process cases. It is not really clear how to write it. > >> I will be appreciate if people review code. Maybe you will suggest > simplifications. It is always difficult to implement concurrent code. > >> > >> Best regards, > >> Denis > > > > -- > www.tudorgirba.com > www.feenk.com > > âLive like you mean it." > > > -- Best regards, Igor Stasenko.

Jan. 4, 2016

Re: [Pharo-dev] do you know we have an issue tracker? (rant)

by Johan Fabry

Just to be sure, did you get notified for this one? https://pharo.fogbugz.com/f/cases/17309/Roassal2-in-Pharo-5-produces-a-segf… > On Jan 4, 2016, at 11:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi guys, > > Soâ¦ last two weeks I was first in Togo with Stef and after taking holidays for the end of the year. > During that time some bugs on new FFI emerged and were talked in this listâ¦ > > Today I came back to work and I wanted to walk through the issues to priorize and start work on fixing themâ¦ and no reports on the issue tracker :( > > So Iâm forced to do email-archeology to dig up the problemsâ¦ or just ignore them until a report arrives. > > What is not in the issue tracker does not exist: PLEASE REPORT YOUR ISSUES. > > thanks, > Esteban > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Jan. 4, 2016