> > >> Dan, Mariano for his PhD did some analysis about number of object used > during typical coding session and we got around 17 %. > >> So mariano would like to see how we can get something like LOOM to > dispose unused objects :) > > > > Are you aware of the work I did that enables class fault detection in > Squeak? > > Yes :) > MDFault that hijack the method category > > But now it is in a separate package:
http://www.squeaksource.com/ClaseUseDiscovery > > If a class has a nil methodDictionary, it causes a fault (ie it sends > recoverFromMDFault to the class). That code then restores the MD in > addition to any anyalysis you want. I never cleaned it up for posterity, but > it enabled lots of interesting work... > > The problem is that we did some experiences (not too advance with mathieu) > and we got all the classes touched after a couple of seconds. > > > By nilling all but a few MDs, and then running some application, > you could > > tell exactly what classes were needed and which were not. > > See the method discoverActiveClasses. > > A special feature even recorded the call stack that caused each > class to be > > touched. > ok this one I was not aware. > I was ;) you can read how to enable that trance and see the results, in the class comment of CUDClassesUseDiscoverer And also in the tests. > > What I was doing was restructuring the entire system as a bunch of > > image segments that could be swapped out and brought in > > on demand -- a sort of user-programmable swapping memory. > > What mariano did so far is to > - read all the image segments code /c included > - find it dangerous > As we discussed recently: http://n4.nabble.com/The-Pharo-Linux-Vm-WAS-Squeak-VM-FT2Plugin-all-Pharo-1-0-rc3-tests-green-tp1694428p1695571.html ImageSegment primitives and the VERY core is working well. The problem is all what is/was implemented on top of that for Project and friends. > - clean the project and etoy related code (for me the simple fact > that you have all the special cases for projects > reveals that there is a deeper fundamental problem. I do not have > the answer but normally the "swapouter" should be generic > and may be provide hooks for specific cases but not do that in the > logic itself. > - define some primitive to use the extra bit to collect some measure > of object used. > - read / understand loom + the same in Java in OOPSLA 2008 > This paper is very related to what we are talking about: http://www.cs.utexas.edu/~mikebond/melt-oopsla-2008.pdf > > Another problem was the size of array which may be double or triple than > what you want to save mariano will be more precise than me. > > This, this was a minor problem. But if you want to use ImageSegment for REALLY big segmentes (Like DabbleDB) you may have a problem as ImageSegment allocates 2 or 3 times the size of the array....maybe adding a primitive to do that directly in disk (of course it will be slower) could be a good idea. Cheers Mariano > > > > > > > - Dan > > > >> > >>> James Ladd <[email protected]> wrote... > >>>>> Hi Pharo-ites, > >>>>> > >>>>> I'm working on a port of Pharo to the Java Virtual Machine called > Redline Smalltalk. > >>>>> (read more here: http://jamesladdcode.com/?p=323) > >>>>> > >>>>> I'm wanting to port every single class over time, but initially > enough to get the > >>>>> compiler working and have a minimum runtime. > >>>>> > >>>>> Of the 1600+/- classes which are those necessary to make a small > workable compiler > >>>>> and runtime environment? > >>> > >>> Hi, James - > >>> > >>> Bert Freudenberg forwarded this along to me, as I'm not on a Pharo > mailing list. > >>> > >>> I think you know of my JSqueak project (a.k.a. Potato) -- a Squeak VM > written in Java. The image that I used with it, is the same that I always > use for this kind of experiment -- mini.image built in Squeak 2.2. > >>> > >>> The reason it is so cool is that it includes browser, editor, compiler, > inspector debugger, and files -- everything you need for self-support. Plus > it has the decompiler, and special temp-name hack, so you can actually > browse sources with temp names before any file system works. My favorite > thing about this image is that although it is only 600k, if you decompile > all its sources, it comprises over 850k of Smalltalk, so it's like a > compressed version of the sources with a full-function IDE thrown in for > free ;-). > >>> > >>> As I said, the image is about 600k, of which 240k is code -- 202 > classes (x2 if you count the metas) with 4590 methods. This should be a > good guide for you in choosing classes to start with. > >>> > >>> You can actually run this image live in JSqueak on the web if you have > Java installed and the planets are aligned correctly... > >>> http://Weather-dimensions.com/Dan/JSqueak.jnlp > >>> Another interesting statistic is that the Java .jar file is only 433k, > including not only the VM, but also the entire image! This is possible > because the image is so small that the pointers in it are mostly zeroes, so > it compresses nicely. I just checked that this runs, and was happy to see > that it putts along at 21 million bytecodes/sec on my laptop. > >>> > >>> I haven't looked recently, but I think you'll find Mini2.2.image or > something like it in the same place where all the historical releases of > Squeak are kept. Let me know if you can't find it. > >>> > >>> Have fun with your project! I hope this helps > >>> > >>> - Dan > >>> _______________________________________________ > >>> 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
