On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel <[email protected]>wrote:
> >> 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. > > > > Hm, is that really going to be worth the trouble? > > This technique reduces the consumption of about 15% of memory. > > >> 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. > >> > >> I have the impression that I simply need to guard the access to the > global poll, which is basically guarding #add: #remove: and #includes: > > > > One of the AtomicCollections might be the right things for you? > > I will have a look at it. > > >> 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. > > > > There isn't any 'multi-threading' like in Java, you got a much more > control version: cooperative on the same priority, preemptive between > priorities. > > 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. > > > > However, much more interesting would be to know what kind of benefit do > you see for such reuse? > > And especially, with Spur around the corner, will it still pay off then? > Or is it an application-specific optimization? > > 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. > > Thanks for all your help guys! You're great! > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > An interesting method I stumbled upon which may help in understanding how these things do work. BlockClosure>>valueUnpreemptively "Evaluate the receiver (block), without the possibility of preemption by higher priority processes. Use this facility VERY sparingly!" "Think about using Block>>valueUninterruptably first, and think about using Semaphore>>critical: before that, and think about redesigning your application even before that! After you've done all that thinking, go right ahead and use it..." | activeProcess oldPriority result semaphore | activeProcess := Processor activeProcess. oldPriority := activeProcess priority. activeProcess priority: Processor highestPriority. result := self ensure: [activeProcess priority: oldPriority].
