Hi henrik if you get a chance to have a look at the slice I uploaded it would be good. I like the idea that people have a look at other code, which is what we do when we integrate now for my own code I always feel nervous :)
Stef On Feb 3, 2010, at 9:40 AM, Henrik Sperre Johansen wrote: > 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 > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
