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

Re: [Pharo-project] Fwd: [Pharo-fuel] Two nice things I did in 2 hours with Fuel

by Craig Latta

> Do I hear "remote tools" ? How would that work, exactly? Wouldn't you want to keep the contexts where they are, and interact with them with remote messages? Otherwise, it seems like differences between the two object memories would cause trouble eventually. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

Aug. 17, 2011

Re: [Pharo-project] Concurrency-Oriented Programming in Pharo

by Eliot Miranda

On Wed, Aug 17, 2011 at 2:24 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi Andrew: > > On 17 Aug 2011, at 22:50, Andrew P. Black wrote: > > > I can imagine that the increasing process-creation time is due to beating > on the memory manager. But why the increasing message-sending time as the > number of processes increases? (Recall that exactly one process is runnable > at any given time). I'm wondering if the scheduler is somehow getting > overwhelmed by all of the non-runable processes that are blocked on > Semaphores in SharedQueue. Any ideas? > Vague from memory, and might confused things (we have tried too many > different things here ;)): > Shouldn't the standard interpreter VM remove the process from the scheduler > list when it is waiting on a semaphore? > Yes, you're right. And any flavour VM will do this. All the processes in the ring except the running one are waiting on the semaphore. > I think, when there is only a single runable process for a given priority, > then the list only contains that one. > > Best regards > Stefan > > > > > (My code is on Squeaksource in project Erlang. But be warned that there > is a simulation of the Erlang "universal server" in there too. To run this > code, look for class ErlangRingTest.) > > > > > > > > > > > > > > -- > 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, Eliot

Aug. 17, 2011

Re: [Pharo-project] Concurrency-Oriented Programming in Pharo

by Igor Stasenko

On 18 August 2011 00:24, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi Andrew: > > On 17 Aug 2011, at 22:50, Andrew P. Black wrote: > >> I can imagine that the increasing process-creation time is due to beating on the memory manager. Â But why the increasing message-sending time as the number of processes increases? Â (Recall that exactly one process is runnable at any given time). Â I'm wondering if the scheduler is somehow getting overwhelmed by all of the non-runable processes that are blocked on Semaphores in SharedQueue. Â Any ideas? > Vague from memory, and might confused things (we have tried too many different things here ;)): > Shouldn't the standard interpreter VM remove the process from the scheduler list when it is waiting on a semaphore? > I think, when there is only a single runable process for a given priority, then the list only contains that one. > Yes, but as far as i remember removing from head/adding to list tail is O(1) operation. It should not depend linearly from the size of a list. > Best regards > Stefan > >> >> (My code is on Squeaksource in project Erlang. Â But be warned that there is a simulation of the Erlang "universal server" in there too. Â To run this code, look for class ErlangRingTest.) >> >> >> >> >> > > > > -- > 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.

Aug. 17, 2011

Re: [Pharo-project] Concurrency-Oriented Programming in Pharo

by Igor Stasenko

On 18 August 2011 00:20, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 August 2011 00:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Andrew, >> >> On Wed, Aug 17, 2011 at 1:50 PM, Andrew P. Black <black(a)cs.pdx.edu> wrote: >>> >>> I was looking at some old slides of Joe Armstrong on Concurrency-orinted >>> programming. Â He set the following challenge: >>> >>> Put N processes in a ring: >>> Send a simple message round the ring M times. >>> Increase N until the system crashes. >>> How long did it take to start the ring? >>> How long did it take to send a message? >>> When did it crash? >>> >>> He gave graphs comparing Erlang, Java and C#. Â I decided to compare Pharo. >>> Â Here is what I got; the creation times are PER PROCESS and the messaging >>> times are PER MESSAGE. >>> >>> first run >>> >>> procs Â Â creation/Âµs Â Â msg/Âµs >>> >>> Â 200 Â Â Â Â Â Â 0 Â Â Â 7.0 >>> Â 500 Â Â Â Â Â Â 0 Â Â Â 9.7 >>> 1000 Â Â Â Â Â Â 2 Â Â Â 15.4 >>> 2000 Â Â Â Â Â Â 1 Â Â Â 21.6 >>> 5000 Â Â Â Â Â Â 13 Â Â Â 31.5 >>> 10000 Â Â Â Â Â 19.9 Â Â 40.7 >>> 20000 Â Â Â Â Â 46.5 Â Â 55.4 >>> 50000 Â Â Â Â Â 130.9 Â 98.0 >>> >>> second run >>> >>> procs Â Â creation/Âµs Â Â msg/Âµs >>> >>> Â 200 Â Â Â Â Â Â 0.0 Â Â 7.0 >>> Â 500 Â Â Â Â Â Â 0.0 Â Â 10.12 >>> 1000 Â Â Â Â Â Â 0.0 Â Â 16.53 >>> 2000 Â Â Â Â Â Â 1.5 Â Â 24.26 >>> 5000 Â Â Â Â Â Â 12.8 Â Â 32.15 >>> 10000 Â Â Â Â Â 28.1 Â Â 39.497 >>> 20000 Â Â Â Â Â 58.15 Â 52.0295 >>> 50000 Â Â Â Â Â 75.1 Â Â 95.581 >>> >>> third run >>> >>> procs Â Â creation/Âµs Â Â msg/Âµs >>> >>> Â 200 Â Â Â Â Â Â 0.0 Â Â 7.0 >>> Â 500 Â Â Â Â Â Â 0.0 Â Â 8.6 >>> 1000 Â Â Â Â Â Â 2.0 Â Â 11.0 >>> 2000 Â Â Â Â Â Â 1.0 Â Â 16.55 >>> 5000 Â Â Â Â Â Â 10.2 Â Â 21.76 >>> 10000 Â Â Â Â Â 12.0 Â Â 49.57 >>> 20000 Â Â Â Â Â 52.35 Â 65.035 >>> 50000 Â Â Â Â Â 91.76 Â 117.1 >>> >>> Each process is a Pharo object (an instance of ERringElement) that >>> contains a counter, a reference to the next ERringElement, and an >>> "ErlangProcess" that is a Process that contains a reference to an instance >>> of SharedQueue (its "mailbox"). >>> >>> The good news is that up to 50k processes, it didn't crash. Â But it did >>> run with increasing sloth. >>> >>> I can imagine that the increasing process-creation time is due to beating >>> on the memory manager. Â But why the increasing message-sending time as the >>> number of processes increases? Â (Recall that exactly one process is runnable >>> at any given time). Â I'm wondering if the scheduler is somehow getting >>> overwhelmed by all of the non-runable processes that are blocked on >>> Semaphores in SharedQueue. Â Any ideas? >> >> If you're using Cog then one reason performance falls off with number of >> processes is context-to-stack mapping, seeÂ 08 Under Cover Contexts and the >> Big Frame-Up. Â Once there are more processes than stack pages every process >> switch faults out a(t least one) frame to a heap contextÂ and faults in a >> heap context to a frame. Â You can experiment by changing the number of stack >> pages (see vmAttributeAt:put:) but you can't have thousands of stack pages; >> it uses too much C stack memory. Â I think the default is 64 pages and >> Teleplace uses ~ 112. Â Each stack page can hold up to approximately 50 >> activations. >> But to be sure what the cause of the slowdown is one could use my >> VMProfiler. Â Has anyone ported this to Pharo yet? > > > Hmm, as to me it doesn't explains why messages/second degrading > linearly to number of processes. > Because after hitting certain limit (all stack pages are full), the > messages/time proportion should not degrade anymore. > Given your explanation, i would expect Â something like following: > 10000 Â Â Â Â Â - Â 49.57 > ... somewhere here we hit stack pages limit ... > 20000 Â Â Â Â Â - Â 65.035 > 30000 Â Â Â Â Â - Â 65.035 > 40000 Â Â Â Â Â - Â 65.035 > 50000 Â Â Â Â Â - Â 65.035 > yes.. except one thing: since contexts are allocated on heap, it means more work for GC, then it explains that it degrading linearly. Andrew, can you play with GC parameters, like increase number of allocations between incremental GCs etc? >>> >>> (My code is on Squeaksource in project Erlang. Â But be warned that there >>> is a simulation of the Erlang "universal server" in there too. Â To run this >>> code, look for class ErlangRingTest.) >> >> >> >> -- >> best, >> Eliot >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Aug. 17, 2011

Re: [Pharo-project] Concurrency-Oriented Programming in Pharo

by Stefan Marr

Hi Andrew: On 17 Aug 2011, at 22:50, Andrew P. Black wrote: > I can imagine that the increasing process-creation time is due to beating on the memory manager. But why the increasing message-sending time as the number of processes increases? (Recall that exactly one process is runnable at any given time). I'm wondering if the scheduler is somehow getting overwhelmed by all of the non-runable processes that are blocked on Semaphores in SharedQueue. Any ideas? Vague from memory, and might confused things (we have tried too many different things here ;)): Shouldn't the standard interpreter VM remove the process from the scheduler list when it is waiting on a semaphore? I think, when there is only a single runable process for a given priority, then the list only contains that one. Best regards Stefan > > (My code is on Squeaksource in project Erlang. But be warned that there is a simulation of the Erlang "universal server" in there too. To run this code, look for class ErlangRingTest.) > > > > > -- 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

Aug. 17, 2011

Re: [Pharo-project] Concurrency-Oriented Programming in Pharo

by Igor Stasenko

On 18 August 2011 00:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Andrew, > > On Wed, Aug 17, 2011 at 1:50 PM, Andrew P. Black <black(a)cs.pdx.edu> wrote: >> >> I was looking at some old slides of Joe Armstrong on Concurrency-orinted >> programming. Â He set the following challenge: >> >> Put N processes in a ring: >> Send a simple message round the ring M times. >> Increase N until the system crashes. >> How long did it take to start the ring? >> How long did it take to send a message? >> When did it crash? >> >> He gave graphs comparing Erlang, Java and C#. Â I decided to compare Pharo. >> Â Here is what I got; the creation times are PER PROCESS and the messaging >> times are PER MESSAGE. >> >> first run >> >> procs Â Â creation/Âµs Â Â msg/Âµs >> >> Â 200 Â Â Â Â Â Â 0 Â Â Â 7.0 >> Â 500 Â Â Â Â Â Â 0 Â Â Â 9.7 >> 1000 Â Â Â Â Â Â 2 Â Â Â 15.4 >> 2000 Â Â Â Â Â Â 1 Â Â Â 21.6 >> 5000 Â Â Â Â Â Â 13 Â Â Â 31.5 >> 10000 Â Â Â Â Â 19.9 Â Â 40.7 >> 20000 Â Â Â Â Â 46.5 Â Â 55.4 >> 50000 Â Â Â Â Â 130.9 Â 98.0 >> >> second run >> >> procs Â Â creation/Âµs Â Â msg/Âµs >> >> Â 200 Â Â Â Â Â Â 0.0 Â Â 7.0 >> Â 500 Â Â Â Â Â Â 0.0 Â Â 10.12 >> 1000 Â Â Â Â Â Â 0.0 Â Â 16.53 >> 2000 Â Â Â Â Â Â 1.5 Â Â 24.26 >> 5000 Â Â Â Â Â Â 12.8 Â Â 32.15 >> 10000 Â Â Â Â Â 28.1 Â Â 39.497 >> 20000 Â Â Â Â Â 58.15 Â 52.0295 >> 50000 Â Â Â Â Â 75.1 Â Â 95.581 >> >> third run >> >> procs Â Â creation/Âµs Â Â msg/Âµs >> >> Â 200 Â Â Â Â Â Â 0.0 Â Â 7.0 >> Â 500 Â Â Â Â Â Â 0.0 Â Â 8.6 >> 1000 Â Â Â Â Â Â 2.0 Â Â 11.0 >> 2000 Â Â Â Â Â Â 1.0 Â Â 16.55 >> 5000 Â Â Â Â Â Â 10.2 Â Â 21.76 >> 10000 Â Â Â Â Â 12.0 Â Â 49.57 >> 20000 Â Â Â Â Â 52.35 Â 65.035 >> 50000 Â Â Â Â Â 91.76 Â 117.1 >> >> Each process is a Pharo object (an instance of ERringElement) that >> contains a counter, a reference to the next ERringElement, and an >> "ErlangProcess" that is a Process that contains a reference to an instance >> of SharedQueue (its "mailbox"). >> >> The good news is that up to 50k processes, it didn't crash. Â But it did >> run with increasing sloth. >> >> I can imagine that the increasing process-creation time is due to beating >> on the memory manager. Â But why the increasing message-sending time as the >> number of processes increases? Â (Recall that exactly one process is runnable >> at any given time). Â I'm wondering if the scheduler is somehow getting >> overwhelmed by all of the non-runable processes that are blocked on >> Semaphores in SharedQueue. Â Any ideas? > > If you're using Cog then one reason performance falls off with number of > processes is context-to-stack mapping, seeÂ 08 Under Cover Contexts and the > Big Frame-Up. Â Once there are more processes than stack pages every process > switch faults out a(t least one) frame to a heap contextÂ and faults in a > heap context to a frame. Â You can experiment by changing the number of stack > pages (see vmAttributeAt:put:) but you can't have thousands of stack pages; > it uses too much C stack memory. Â I think the default is 64 pages and > Teleplace uses ~ 112. Â Each stack page can hold up to approximately 50 > activations. > But to be sure what the cause of the slowdown is one could use my > VMProfiler. Â Has anyone ported this to Pharo yet? Hmm, as to me it doesn't explains why messages/second degrading linearly to number of processes. Because after hitting certain limit (all stack pages are full), the messages/time proportion should not degrade anymore. Given your explanation, i would expect something like following: 10000 - 49.57 ... somewhere here we hit stack pages limit ... 20000 - 65.035 30000 - 65.035 40000 - 65.035 50000 - 65.035 >> >> (My code is on Squeaksource in project Erlang. Â But be warned that there >> is a simulation of the Erlang "universal server" in there too. Â To run this >> code, look for class ErlangRingTest.) > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko AKA sig.

Aug. 17, 2011

Re: [Pharo-project] Concurrency-Oriented Programming in Pharo

by StÃ©phane Ducasse

> > Each process is a Pharo object (an instance of ERringElement) that contains a counter, a reference to the next ERringElement, and an "ErlangProcess" that is a Process that contains a reference to an instance of SharedQueue (its "mailbox"). > > The good news is that up to 50k processes, it didn't crash. But it did run with increasing sloth. > > I can imagine that the increasing process-creation time is due to beating on the memory manager. But why the increasing message-sending time as the number of processes increases? (Recall that exactly one process is runnable at any given time). I'm wondering if the scheduler is somehow getting overwhelmed by all of the non-runable processes that are blocked on Semaphores in SharedQueue. Any ideas? > > If you're using Cog then one reason performance falls off with number of processes is context-to-stack mapping, see 08 Under Cover Contexts and the Big Frame-Up. Once there are more processes than stack pages every process switch faults out a(t least one) frame to a heap context and faults in a heap context to a frame. You can experiment by changing the number of stack pages (see vmAttributeAt:put:) but you can't have thousands of stack pages; it uses too much C stack memory. I think the default is 64 pages and Teleplace uses ~ 112. Each stack page can hold up to approximately 50 activations. > > But to be sure what the cause of the slowdown is one could use my VMProfiler. Has anyone ported this to Pharo yet? not that I know. Where is the code :) > > > (My code is on Squeaksource in project Erlang. But be warned that there is a simulation of the Erlang "universal server" in there too. To run this code, look for class ErlangRingTest.) > > > > -- > best, > Eliot >

Aug. 17, 2011

Re: [Pharo-project] what are the comments of cull: cull: cull:cull: and friends?

by Igor Stasenko

On 17 August 2011 23:57, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 17.08.2011 22:29, Philippe Marschall wrote: >> >> On 17.08.2011 22:17, StÃ©phane Ducasse wrote: >>> >>> I wrote >>> >>> >>> cull: anArg >>> Â Â Â Â "Execute the receiver with one or zero argument. >>> >>> Â Â Â Â [ 1 + 2 ] cull: 5 >>> Â Â Â Â Â Â Â Â returns 3 >>> Â Â Â Â [ :x | 1+ 2 + x] cull: 5 >>> Â Â Â Â Â Â Â Â returns 8 >>> Â Â Â Â " >>> Â Â Â Â ^numArgs = 0 >>> Â Â Â Â Â Â Â Â ifTrue: [self value] >>> Â Â Â Â Â Â Â Â ifFalse: [self value: anArg] >>> >> >> So it's like #valueWithPossibleArgument:? > > Almost. > cull: raises error if given blocks with too many args, > valueWithPossibleArgument(s): evaluates with the extra args as nil. >> >> Â Why do we need two methods >> that do the same thing? > > Because valueWithPossibleArguments was there first, and we can't simply > remove it. > cull is more natural to use in 99.9% of the cases. > > Also, #cull: protocol only goes up to 4 arguments, mirroring #value: > (#cullWithArguments: not being present is mostly an oversight though... ) > yes yes, cull is cool. no need to provide more arguments :) Also, it is easier to use and remember, because every time i need to use valueWithPossibleBlahblah i always forgetting the right selector and need to lookup the implementation. -- Best regards, Igor Stasenko AKA sig.

Aug. 17, 2011

Re: [Pharo-project] what are the comments of cull: cull: cull:cull: and friends?

by Igor Stasenko

On 17 August 2011 23:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I prefer execute :) > because evaluate looks like you don't run fast and generate possibly assembly on the fly. :) > I stopped long time ago to use evaluate because people also think that Smalltalk is slow because of that evaluation.... > silly idiots but they are out there. > Hehe.. Smalltalk is fast. > Stef (Ze mass educator) > > > On Aug 17, 2011, at 10:29 PM, Igor Stasenko wrote: > >> execute or evaluate? >> >> >> On 17 August 2011 23:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> I wrote >>> >>> >>> cull: anArg >>> Â Â Â Â "Execute the receiver with one or zero argument. >>> >>> Â Â Â Â [ 1 + 2 ] cull: 5 >>> Â Â Â Â Â Â Â Â returns 3 >>> Â Â Â Â [ :x | 1+ 2 + x] cull: 5 >>> Â Â Â Â Â Â Â Â returns 8 >>> Â Â Â Â " >>> Â Â Â Â ^numArgs = 0 >>> Â Â Â Â Â Â Â Â ifTrue: [self value] >>> Â Â Â Â Â Â Â Â ifFalse: [self value: anArg] >>> >>> >>> >>> cull: firstArg cull: secondArg >>> Â Â Â Â "Execute the receiver with two or less arguments. >>> >>> Â Â Â Â [ 1 + 2 ] cull: 5 cull: 6 >>> Â Â Â Â Â Â Â Â returns 3 >>> Â Â Â Â [ :x | 1+ 2 + x] cull: 5 >>> Â Â Â Â Â Â Â Â returns 8 >>> Â Â Â Â [ :x | 1+ 2 + x] cull: 5 cull: 3 >>> Â Â Â Â Â Â Â Â returns 8 >>> Â Â Â Â [ :x : y | 1+ y + x] cull: 5 cull: 2 >>> Â Â Â Â Â Â Â Â returns 8 >>> Â Â Â Â " >>> Â Â Â Â ^numArgs < 2 >>> Â Â Â Â Â Â Â Â ifTrue: [self cull: firstArg] >>> Â Â Â Â Â Â Â Â ifFalse: [self value: firstArg value: secondArg] >>> >>> >>> cull: firstArg cull: secondArg cull: thirdArg >>> Â Â Â Â "Execute the receiver with three or less arguments. Check cull:cull: for examples" >>> >>> Â Â Â Â ^numArgs < 3 >>> Â Â Â Â Â Â Â Â ifTrue: [self cull: firstArg cull: secondArg] >>> Â Â Â Â Â Â Â Â ifFalse: [self value: firstArg value: secondArg value: thirdArg] >>> >>> >>> cull: firstArg cull: secondArg cull: thirdArg cull: fourthArg >>> Â Â Â Â "Execute the receiver with four or less arguments. Check cull:cull: for examples" >>> Â Â Â Â ^numArgs < 4 >>> Â Â Â Â Â Â Â Â ifTrue: [self cull: firstArg cull: secondArg cull: thirdArg] >>> Â Â Â Â Â Â Â Â ifFalse: [self value: firstArg value: secondArg value: thirdArg value: fourthArg] >>> >>> Will add a bug entry >>> >>> Stef >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > -- Best regards, Igor Stasenko AKA sig.

Aug. 17, 2011

Re: [Pharo-project] Concurrency-Oriented Programming in Pharo

by Eliot Miranda

Hi Andrew, On Wed, Aug 17, 2011 at 1:50 PM, Andrew P. Black <black(a)cs.pdx.edu> wrote: > I was looking at some old slides of Joe Armstrong on Concurrency-orinted > programming. He set the following challenge: > > Put N processes in a ring: > Send a simple message round the ring M times. > Increase N until the system crashes. > How long did it take to start the ring? > How long did it take to send a message? > When did it crash? > > He gave graphs comparing Erlang, Java and C#. I decided to compare Pharo. > Here is what I got; the creation times are PER PROCESS and the messaging > times are PER MESSAGE. > > first run > > procs creation/Âµs msg/Âµs > > 200 0 7.0 > 500 0 9.7 > 1000 2 15.4 > 2000 1 21.6 > 5000 13 31.5 > 10000 19.9 40.7 > 20000 46.5 55.4 > 50000 130.9 98.0 > > second run > > procs creation/Âµs msg/Âµs > > 200 0.0 7.0 > 500 0.0 10.12 > 1000 0.0 16.53 > 2000 1.5 24.26 > 5000 12.8 32.15 > 10000 28.1 39.497 > 20000 58.15 52.0295 > 50000 75.1 95.581 > > third run > > procs creation/Âµs msg/Âµs > > 200 0.0 7.0 > 500 0.0 8.6 > 1000 2.0 11.0 > 2000 1.0 16.55 > 5000 10.2 21.76 > 10000 12.0 49.57 > 20000 52.35 65.035 > 50000 91.76 117.1 > > Each process is a Pharo object (an instance of ERringElement) that contains > a counter, a reference to the next ERringElement, and an "ErlangProcess" > that is a Process that contains a reference to an instance of SharedQueue > (its "mailbox"). > > The good news is that up to 50k processes, it didn't crash. But it did run > with increasing sloth. > > I can imagine that the increasing process-creation time is due to beating > on the memory manager. But why the increasing message-sending time as the > number of processes increases? (Recall that exactly one process is runnable > at any given time). I'm wondering if the scheduler is somehow getting > overwhelmed by all of the non-runable processes that are blocked on > Semaphores in SharedQueue. Any ideas? > If you're using Cog then one reason performance falls off with number of processes is context-to-stack mapping, see 08 Under Cover Contexts and the Big Frame-Up<http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the…>. Once there are more processes than stack pages every process switch faults out a(t least one) frame to a heap context and faults in a heap context to a frame. You can experiment by changing the number of stack pages (see vmAttributeAt:put:) but you can't have thousands of stack pages; it uses too much C stack memory. I think the default is 64 pages and Teleplace uses ~ 112. Each stack page can hold up to approximately 50 activations. But to be sure what the cause of the slowdown is one could use my VMProfiler. Has anyone ported this to Pharo yet? > (My code is on Squeaksource in project Erlang. But be warned that there is > a simulation of the Erlang "universal server" in there too. To run this > code, look for class ErlangRingTest.) > -- best, Eliot

Aug. 17, 2011