<div dir="ltr"><div class="gmail_extra"><div><div dir="ltr"><div>Eliot,</div></div></div><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 5:46 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div dir="auto"><div>Hi Phil, Hi ClassBuilder people,</div>
<div><br>On Mar 25, 2014, at 5:16 AM, "<a href="mailto:phil@highoctane.be" target="_blank">phil@highoctane.be</a>" <<a href="mailto:phil@highoctane.be" target="_blank">phil@highoctane.be</a>> wrote:<br>
<br></div><div><span></span></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div><div dir="ltr"><div>On Tue, Mar 25, 2014 at 1:05 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br>
</div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<br><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 March 2014 22:54, <a href="mailto:phil@highoctane.be" target="_blank">phil@highoctane.be</a> <span dir="ltr"><<a href="mailto:phil@highoctane.be" target="_blank">phil@highoctane.be</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><div>On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel <span dir="ltr"><<a href="mailto:alexandre.bergel@me.com" target="_blank">alexandre.bergel@me.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">>> I am working on a memory model for expandable collection in Pharo. Currently, OrderedCollection, Dictionary and other expandable collections use a internal array to store their data. My new collection library recycle these array instead of letting the garbage collector dispose them. I simply insert the arrays in an ordered collection when an array is not necessary anymore. And I remove one when I need one.<br>
><br>
> Hm, is that really going to be worth the trouble?<br>
<br>
This technique reduces the consumption of about 15% of memory.<br>
<br>
>> At the end, #add: and #remove: are performed on these polls of arrays. I haven’t been able to spot any problem regarding concurrency and I made no effort in preventing them. I have a simple global collection and each call site of "OrderedCollection new” can pick an element of my global collection.<br>
>><br>
>> I have the impression that I simply need to guard the access to the global poll, which is basically guarding #add: #remove: and #includes:<br>
><br>
> One of the AtomicCollections might be the right things for you?<br>
<br>
I will have a look at it.<br>
<br>
>> What is funny, is that I did not care at all about multi-threading and concurrency, and I have not spotted any problem so far.<br>
><br>
> There isn’t any ‘multi-threading’ like in Java, you got a much more control version: cooperative on the same priority, preemptive between priorities.<br>
> So, I am not surprised. And well, these operations are likely not to be problematic when they are racy, except when the underling data structure could get into an inconsistent state itself. The overall operations (adding/removing/searing) are racy on the application level anyway.<br>
><br>
> However, much more interesting would be to know what kind of benefit do you see for such reuse?<br>
> And especially, with Spur around the corner, will it still pay off then? Or is it an application-specific optimization?<br>
<br>
I am exploring a new design of the collection library of Pharo. Not all the (academic) ideas will be worth porting into the mainstream of Pharo. But some of them yes.<br>
<br>
Thanks for all your help guys! You’re great!<br>
<br>
Cheers,<br>
Alexandre<br>
<span><font color="#888888"><br>
--<br>
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:<br>
Alexandre Bergel <a href="http://www.bergel.eu" target="_blank">http://www.bergel.eu</a><br>
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.<br>
<br>
<br>
<br></font></span></blockquote><div><br></div></div></div><div>An interesting method I stumbled upon which may help in understanding how these things do work. </div><div><br></div><div>BlockClosure>>valueUnpreemptively</div>
<div>
<span style="white-space:pre-wrap"> </span>"Evaluate the receiver (block), without the possibility of preemption by higher priority processes. Use this facility VERY sparingly!"</div><div><span style="white-space:pre-wrap"> </span>"Think about using Block>>valueUninterruptably first, and think about using Semaphore>>critical: before that, and think about redesigning your application even before that! </div>
<div><span style="white-space:pre-wrap"> </span>After you've done all that thinking, go right ahead and use it..."</div><div><span style="white-space:pre-wrap"> </span>| activeProcess oldPriority result semaphore |</div>
<div><span style="white-space:pre-wrap"> </span>activeProcess := Processor activeProcess.</div><div><span style="white-space:pre-wrap"> </span>oldPriority := activeProcess priority.</div><div><span style="white-space:pre-wrap"> </span>activeProcess priority: Processor highestPriority.</div>
<div><span style="white-space:pre-wrap"> </span>result := self ensure: [activeProcess priority: oldPriority]. </div></div><br></div></div>
</blockquote></div><br>I would not recommend you to use this method for anything.<br></div><div class="gmail_extra">This method heavily relies on how process scheduler works, and in case of any changes, it may break everything.<br>
</div><div class="gmail_extra">For the sake of programming, one shall never assume there is a way to "stop the world while i busy doing something".</div></div></blockquote><div><br></div><div>If you reshape the world, it makes sense. I was looking at how classes were migrated, that's why I found it. </div>
<div>And all of the new Pharo way of doing these things.</div><div><br></div><div>Hey, it is becoming really cool down there. Martin and Camille have been hard at work. Kudos!</div><div><br></div><div>migrateClasses: old to: new using: anInstanceModification</div>
<div><span style="white-space:pre-wrap"> </span>instanceModification := anInstanceModification.</div><div><span style="white-space:pre-wrap"> </span>old ifEmpty: [ ^ self ].</div><div><span style="white-space:pre-wrap"> </span>[</div>
<div><span style="white-space:pre-wrap"> </span>1 to: old size do: [ :index |</div><div><span style="white-space:pre-wrap"> </span>self updateClass: (old at: index) to: (new at: index)].</div><div><span style="white-space:pre-wrap"> </span>old elementsForwardIdentityTo: new.</div>
<div><span style="white-space:pre-wrap"> </span>" Garbage collect away the zombie instances left behind in garbage memory in #updateInstancesFrom: "</div><div><span style="white-space:pre-wrap"> </span>" If we don't clean up this garbage, a second update would revive them with a wrong layout! "</div>
<div><span style="white-space:pre-wrap"> </span>" (newClass rather than oldClass, since they are now both newClass) "</div><div><span style="white-space:pre-wrap"> </span>Smalltalk garbageCollect.</div>
<div><span style="white-space:pre-wrap"> </span>] valueUnpreemptively</div></div></div></div></div></blockquote><div><br></div><div><br></div>The global GC here is pretty unfortunate. It is there because the VM used to leave old instances lying around. It works like this:</div>
<div dir="auto"><br></div></div></blockquote><div><br></div><div>Uh,oh, yes, GC's are expensive things.</div><div>At the moment I am working with TimeSeries data and that's a lot of entries. And the entries are under developement, so, morphing a lot.<br>
</div><div>With a 64-bit VM, all hell will break loose I think. Even on Java VM, they advise not to use too much memory with -Xmx for that reason. (Well,the new GCs are multithreaded as in:</div><div><br></div><div><p style="margin:0px 0px 10px;padding:0px;list-style:none;line-height:16px;font-size:12px;color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif">
<strong style="margin:0px;padding:0px;list-style:none">Which garbage collector should I use for a very large 64-bit heaps?</strong></p><p style="margin:0px 0px 10px;padding:0px;list-style:none;line-height:16px;font-size:12px;color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif">
The major advantage of a 64-bit Java implementation is to be able to create and use more Java objects. It is great to be able to break these 2GB limits. Remember, however, that this additional heap must be garbage collected at various points in your application's life span. This additional garbage collection can cause large pauses in your Java application if you do not take this into consideration. The Hotspot VM has a number of garbage collection implementations which are targetted at Java applications with large heaps. We recommend enabling one of the Parallel or Concurrent garbage collectors when running with very large heaps. These collectors attempt to minimize the overhead of collection time by either collecting garbage concurrent with the execution of your Java application or by utilizing multiple CPUs during collections to ge the job done faster. <span class="" style="margin:0px;padding:0px;list-style:none"> </span> <br style="margin:0px;padding:0px;list-style:none">
For more information on these garbage collection modes and how to select them please refer to the Hotspot GC tuning guide which can be found here: <a href="http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html" style="margin:0px;padding:0px;list-style:none;color:rgb(31,79,130);text-decoration:none">Tuning Garbage Collection with the 5.0 Java Virtual Machine</a></p>
<p style="margin:0px 0px 10px;padding:0px;list-style:none;line-height:16px;font-size:12px;color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif">in <a href="http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#64bit_performance">http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#64bit_performance</a></p>
<p style="margin:0px 0px 10px;padding:0px;list-style:none;line-height:16px;font-size:12px;color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif">and in <a href="http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html">http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html</a></p>
<p style="margin:0px 0px 10px;padding:0px;list-style:none"><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px;line-height:16px">A) The Parallel GC</span></p><p style="margin:0px 0px 10px;padding:0px;list-style:none">
<span style="font-size:12px;line-height:16px;color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif">With the -XX:+UseParallelOldGC option, the GC is both a multithreaded young generation collector and multithreaded old generation collector. It is also a multithreaded compacting collector. HotSpot does compaction only in the old generation. Young generation in HotSpot is considered a copy collector; therefore, there is no need for compaction.</span><br>
</p><p style="margin:0px 0px 10px;padding:0px;list-style:none"><span style="font-size:12px;line-height:16px;color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif">Compacting describes the act of moving objects in a way that there are no holes between objects. After a garbage collection sweep, there may be holes left between live objects. Compacting moves objects so that there are no remaining holes. It is possible that a garbage collector be a non-compacting collector. Therefore, the difference between a parallel collector and a parallel compacting collector could be the latter compacts the space after a garbage collection sweep. The former would not.</span><br>
</p><p style="margin:0px 0px 10px;padding:0px;list-style:none;line-height:16px;font-size:12px;color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif">B) The Concurrent Mark Sweep (CMS) Collector<br></p><p style="margin:0px 0px 10px;padding:0px;list-style:none">
<span style="font-size:12px;line-height:16px;color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif">The Concurrent Mark Sweep (CMS) collector (also referred to as the concurrent low pause collector) collects the tenured generation. It attempts to minimize the pauses due to garbage collection by doing most of the garbage collection work concurrently with the application threads. Normally the concurrent low pause collector does not copy or compact the live objects. A garbage collection is done without moving the live objects. If fragmentation becomes a problem, allocate a larger heap.</span><br>
</p><p style="margin:0px 0px 10px;padding:0px;list-style:none"><span style="font-size:12px;line-height:16px;color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif">Note: CMS collector on young generation uses the same algorithm as that of the parallel collector.</span><br>
</p><p style="margin:0px 0px 10px;padding:0px;list-style:none">Are you looking into such things? (Or maybe they are in already...)</p><p style="margin:0px 0px 10px;padding:0px;list-style:none">Multicore may be put to good use there I guess.</p>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div dir="auto"></div>
<div>we want to reshape instances of class C, e.g. by adding an inst var, and so</div><div><br></div><div>1. create C', which is C plus an inst var</div><div dir="auto">2. create a parallel set of instances of class C', one for each instance of class C</div>
<div dir="auto">3. for each corresponding pair of instances copy state from the instance of C to the instance of C'</div><div dir="auto">4. forward-become the instances of C to the instances of C' (now no references to the instances of C remain)</div>
<div dir="auto">5. become C to C' (now C' is the new C)</div><div dir="auto"><br></div><div dir="auto">The bug is that the old instances of C are still in the heap. Because of the become in 5. they look like instances of the new C, but are the wrong size; they lack space for the new inst var. They're not reachable (4. replaced all references to them with references to the instances of C') but they can be resurrected through allInstances (someInstance,nextInstance) which works not by following references from the roots (Smalltalk and the activeProcess) but by scanning objects in the heap.</div>
<div dir="auto"><br></div><div dir="auto">However, this was "fixed" in</div><div dir="auto"><br></div><div dir="auto"><div dir="auto"><span style="white-space:pre-wrap"> </span>Name: VMMaker.oscog-eem.254</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>Author: eem</div><div dir="auto"><span style="white-space:pre-wrap"> </span>Time: 11 January 2013, 7:05:37.389 pm</div><div dir="auto"><span style="white-space:pre-wrap"> </span>UUID: 74e6a299-691e-4f7d-986c-1a7d3d0ec02c</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>Ancestors: VMMaker.oscog-eem.253</div><div dir="auto"><br></div><div dir="auto"><span style="white-space:pre-wrap"> </span>Fix becomeForward: so that objects whose references are deleted are</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>freed and can no longer be resurrected via allObjects or allInstances.</div><div dir="auto"><br></div><div>The change is to free the objects replaced in a forwardBecome so they are no longer objects (effectively their class is null (not nil, but 0)). So they can't be resurrected and hence the global GC is un necessary. The Newspeak folks, in particular Ryan Macnak, spotted this and encouraged me to make the change. It of course speeds up instance mutation considerably.</div>
<div><br></div><div>I say fixed because there was a bug tail:</div><div><br></div></div><div dir="auto"><div dir="auto"><span style="white-space:pre-wrap"> </span>Name: VMMaker.oscog-eem.258</div><div dir="auto"><span style="white-space:pre-wrap"> </span>Author: eem</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>Time: 18 January 2013, 11:01:23.072 am</div><div dir="auto"><span style="white-space:pre-wrap"> </span>UUID: da1433f1-de50-475f-be33-f462b300a2ea</div><div dir="auto">
<span style="white-space:pre-wrap"> </span>Ancestors: VMMaker.oscog-eem.257</div><div dir="auto"><br></div><div dir="auto"><span style="white-space:pre-wrap"> </span>Fix becomeForward: when the rootTable overflows. There were two</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>bugs here. One is that initializeMemoryFirstFree: used to clear the</div><div dir="auto"><span style="white-space:pre-wrap"> </span>needGCFlag so if the rootTable overflowed noteAsRoot:headerLoc:'s setting of the needGCFlag would be undone after the sweep.</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>The other is that rootTable overflow was indicated by</div><div dir="auto"><span style="white-space:pre-wrap"> </span>rootTableCount >= RootTableSize which could be undone by</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>becomeForward: freeing roots which need to be removed from</div><div dir="auto"><span style="white-space:pre-wrap"> </span>the rootTable. At some point in becomeForward the rootTable would</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>fill but at a later point a root would be freed, causing the table to</div><div dir="auto"><span style="white-space:pre-wrap"> </span>become not full.</div>
<div dir="auto"><br></div><div dir="auto"><span style="white-space:pre-wrap"> </span>The fix is two fold. 1. Add an explicit rootTableOverflowed flag</div><div dir="auto"><span style="white-space:pre-wrap"> </span>instead of relying on rootTableCount >= RootTableSize.</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>2. move the clearing of the needGCFlag to the GC routines.</div><div dir="auto"><span style="white-space:pre-wrap"> </span>Remove unnecessary senders of needGCFlag: false, and remove</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>the accessor.</div><div dir="auto"><br></div><div dir="auto"><span style="white-space:pre-wrap"> </span>Name: VMMaker.oscog-eem.255</div><div dir="auto"><span style="white-space:pre-wrap"> </span>Author: eem</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>Time: 12 January 2013, 6:28:41.398 pm</div><div dir="auto"><span style="white-space:pre-wrap"> </span>UUID: 51e53ec1-8caf-41f6-9293-1088ef4b82d8</div><div dir="auto">
<span style="white-space:pre-wrap"> </span>Ancestors: VMMaker.oscog-eem.254</div><div dir="auto"><br></div><div dir="auto"><span style="white-space:pre-wrap"> </span>[New[Co]]ObjectMemory:</div><div dir="auto"><span style="white-space:pre-wrap"> </span>Fix freeing of objects for becomeForward:. Remove freed young</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>roots from the rootsTable. Filter freed objects pointet to from the</div><div dir="auto"><span style="white-space:pre-wrap"> </span>extraRootsTable (because these locations can change it is wrong</div>
<div dir="auto"><span style="white-space:pre-wrap"> </span>to remove entries from the extraRootsTable).</div><div><span><br></span></div><div><span>But the bottom line is that, at least on the current Cog VM, that global GC is unnecessary. David, Tim, this still needs to be folded into ObjectMemory in the standard interpreter. But doing so is very worth-while. Monticello loads are noticeably faster.</span></div>
</div></div></blockquote><div><br></div><div>Current version of the VM: (don't know if the VMMaker.oscog-eem.258 is in there. Esteban? Igor?)</div><div><br></div><div>Smalltalk vm version 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Mar 17 2014<br>
</div><div><div>NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Mar 17 2014</div><div><a href="https://github.com/pharo-project/pharo-vm.git">https://github.com/pharo-project/pharo-vm.git</a> Commit: 6e08ad296c0df6c1a4215a5dada5380c897dc2fe Date: 2014-03-17 14:45:12 +0100 By: Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com">estebanlm@gmail.com</a>> Jenkins build #14811</div>
</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div dir="auto">
<div><span><br></span><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>KR</div><div>Phil </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><span><font color="#888888"></font></span></div><span><font color="#888888"><div class="gmail_extra"><br><br></div><div class="gmail_extra">
-- <br>Best regards,<br>Igor Stasenko.
</div></font></span></div>
</blockquote></div></div></div></blockquote><br><br><span>Eliot (phone)</span></div></div></div>
</blockquote></div><br></div></div>