On 02.02.2010 23:06, John M McIntosh wrote: > 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. > I have seen no problems with finalization not working (eventually, which I guess is what Bill alluded to). I 100% agree with having it as standard for the common file handle creation methods. There are cases such as existsFile:, newFileNamed:do: and friends, etc., where you only use a stream temporarily and can close it before the end of the method's scope, not registering it in those cases does make a difference. (Which is what the test was meant to show). Whether it would actually be better to just not close it manually, and wait for the finalization to do it instead, might be worth investigating. > 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. In the example, the stream is closed manually by the old version of RemoteString text. Thus, no finalization really triggers in this case, but the close still triggers a rehash of the weak FileRegistry on every close. > > > 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. >
As stated above, the handles were closed manually, thus I'd wager the finalization process never did get to run to clean them up. Either way, as long as it consistently reproduces shorter runtimes, does it really matter what the causes were? Cheers, Henry _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
