Ok, I can speak from experience that the file clean up logic does work in Squeak because in Sophie we would open 100's of files in a big project and we did discover a bug in the finalization logic that the FileStream uses to cleanup linkages after the copy of the object is made in the finalization logic.
This was not the fault of how the finalization logic works, rather it was a bug in the user code. Now the reason for the finalization on streams is that in most/all? file systems system resources are a finite resource, (see denial of service attacks). Isn't it 1024 file handles in os-x? If you allocate a file,work with it, then GC the stream without closing then Squeak might be fine, but the actual operating system resource is dangling. So you need the finalization to cleanup, unless you can get the programmer always to promise to close the handle. Perhaps when an ensure:[] (always used everywhere?). However the model usually used is open the file, and sometime in the future close it via some other logic path we can't force fit the programmer into an ensure: [] pattern. So on a file handle open failure the code code runs a full GC because you could have the case where you have 900 handles allocated by GCed objects in OldSpace. Since object in Old Space could be dead, but not realized as dead yet a full gc is required to clean them up, which triggers the finalization, which frees the zombie handles. This is not a fault of the finalization logic, it's to do with having multiple collectors and wanting to minimize the effort put into looking for dead objects, until we really really have to... So the logic on failure will trigger a full GC/finalization process, and then on the 2nd attempt if required fail because you've actually run into a system resource issue, or some other fatal file open error. I am wondering here if your benchmark results are clouded by having a fullGC run. I'd check fullGC count before/after to see how it's being changed. On 2010-02-02, at 4:00 AM, Schwab,Wilhelm K wrote: > Henry, > > I would not toss your first thought too quickly. Staying clear of > finalization is a big benefit. I have never been able to trust it (for > files) on Dolphin, which has a remarkably better implementation of weak > collections and finalization than Squeak/Pharo. > > Bill > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Henrik > Johansen > Sent: Tuesday, February 02, 2010 5:08 AM > To: [email protected] > Subject: Re: [Pharo-project] readOnlyFileNamed:do: vs. ... > > Scratch that. It's what I would have done with a fileNamed:do: selector :) > > The main difference is readOnlyFileNamed:do: does not evaluate the block if > file creation returns nil, while the second code errors out with stream dnu > setConverterFromCode if the file could not be opened for any reason. > > Cheers, > Henry > > Den 02.02.2010 11:02, skrev Henrik Johansen: >> My guess is he uses a method which does not register the file in >> FileRegistry, thus avoids a WeakDict cleanup when he closes the file >> after the block has been evaluated. >> (eg readOnlyFileNamed:do: vs. readOnlyFileNamed:) Thus, a lot of time >> is saved from not doing weak registry cleanup. >> (Which can be a large chunk of the total time when you do many small >> operations). >> >> Cheers, >> Henry >> >> Den 02.02.2010 10:50, skrev Stéphane Ducasse: >> >>> Nicolas I saw that in squeak you changed and use readOnlyFileNamed:do: >>> I like it but I would like to understand what is the key advantage >>> >>> >>> fromFileNamed: aName >>> FileStream readOnlyFileNamed: aName do: [:stream | >>> stream setConverterForCode. >>> self fileInFrom: stream] >>> >>> fromFileNamed: aName >>> | stream | >>> stream := FileStream readOnlyFileNamed: aName. >>> stream setConverterForCode. >>> [self fileInFrom: stream] ensure: [stream close]. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <[email protected]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
