Re: Redline Smalltalk
Locked
 
|
James Ladd <[hidden email]>
wrote...
Hi Pharo-ites, 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...
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi,
2010/4/6 Dan Ingalls <[hidden email]>: > 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 ;-). > ... > 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. let me add that the project - it is unfortunately in a somewhat dormant state due to lack of manpower - can be found here: http://sourceforge.net/projects/potatovm/ Some extensions to the original JSqueak were implemented; mostly they had to do with colour and font handling. The VM also includes an optimisation for Large...Integer objects, utilising Java BigIntegers as shadows. HPI students once approached a JIT compiler (not finished); the code is available by request. Best, Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Dan Ingalls
Hi dan
This is fun because I was rereading the miniimage contents and started to think in terms of package reorganization to support a mini image. I reread also Spoon a bit and I was looking at the nuturning. Dan it would be nice if you could merge the potatoe change into Jsqueak? 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 :) Stef > James Ladd <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi, Stef -
>This is fun because I was rereading the miniimage contents and started to think in terms of package reorganization to support a mini image. >I reread also Spoon a bit and I was looking at the nuturning. >Dan it would be nice if you could merge the potatoe change into Jsqueak? Potato is JSqueak. I don't get it. >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? 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... 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. 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. This all worked at one point. Swapping of projects was a bit flakier because of our weak discipline on pointer scope, but it even worked in many cases. Where I was going with the whole "reorganizeEverything" project was that the SystemDictionary would be partitioned into many separate dictionaries in each project, and that namespaces would be the same as the project swapping unit, and the whole thing would be simple and fast. It actually worked once (;-) also. Loom was cool, but it could never come close to the speed of imageSegments. I played around with swapping out the entire VM Support category with all classes and methods, and it would swap in the entirety in less than 200 milliseconds, and this was a decade ago. Sorry for the long digression, but maybe some of this thinking or even the actual mechanism can be of use to your experiments. - Dan > >> James Ladd <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >_______________________________________________ >Pharo-project mailing list >[hidden email] >http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Dan Ingalls
Hi Dan, > Bert Freudenberg forwarded this along to me, as I'm not on a Pharo > mailing list. > > Have fun with your project! I hope this helps > > - Dan Looking for a hot date? View photos of singles in your area! _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Dan Ingalls
On Apr 6, 2010, at 11:01 PM, Dan Ingalls wrote: > Hi, Stef - > >> This is fun because I was rereading the miniimage contents and started to think in terms of package reorganization to support a mini image. >> I reread also Spoon a bit and I was looking at the nuturning. >> Dan it would be nice if you could merge the potatoe change into Jsqueak? > > Potato is JSqueak. I don't get it. I know :) Now having two different repositories with not synchronized code is not really good. This is was I thought that either you put a pointer to potatoe on your page or better you merge their changes. >> 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 > 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. > 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 - 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 next steps - getting married - build some tools to collect thiner grained information One problem we saw with IS is that as soon as you have a reference from outside the root graph to inside your graph, this subgraph does not get saved (because not marked) and this may led to brittle system. 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 all worked at one point. Swapping of projects was a bit flakier > because of our weak discipline on pointer scope, but it > even worked in many cases. > > Where I was going with the whole "reorganizeEverything" project was that the SystemDictionary would be partitioned into many separate dictionaries in each project, and that namespaces would be the same as the project swapping unit, and the whole thing would be simple and fast. It actually worked once (;-) also. this is interesting. I'm not convinced that I would unify namespace and project (but this is the case in a module system). Now the question is how to dynamically modularize a system. Because are static organization (which are good for code management) doomed to failed when we look at them from a use point of view? > > Loom was cool, but it could never come close to the speed of imageSegments. I played around with swapping out the entire VM Support category with all classes and methods, and it would swap in the entirety in less than 200 milliseconds, and this was a decade ago. > > Sorry for the long digression, but maybe some of this thinking or even the actual mechanism can be of use to your experiments. Yes now we were thinking that imageSegments should not rely on the internal C organization of objects. > > - Dan > >> >>> James Ladd <[hidden email]> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Hi Dan. First let me say that it is really cool to have you in the list :) Yes, I know about that MD faults and I did some experiments with it. As part of my work, I remove that from core and I put it in a separate package. I also rewrite some things a little. I invite you, if you want/have time to look at it. It is in http://www.squeaksource.com/ClaseUseDiscovery You can see the class comments of CUDClassesUseDiscoverer and also the CUDClassesUseDiscovererTest This tool is working perfect. I sent an email some weeks ago: http://n4.nabble.com/ANN-ClaseUseDiscovery-tool-td1296859.html#a1296861 Now, my conclusions were that it is a great tool but it has the problem that when ever you do a Smalltalk allClassesDo or similar, it brings all the classes back. I saw there was the *gentlly* so that you could do allClassesDoGently etc and the gently checks for isInMemory, where in ImageSegmentRootStub answers false. The problem is that you have to put those gently everywhere and once you forget about that....you are dead. The other problem is the gradunalirity. I mean, even when sending a simple message to a single object of a class, the whole class is loaded. Even with all that, it was great to see and have in mind a percentage of the used classes against different scenarios. Cheers Mariano - Dan _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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.
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 This paper is very related to what we are talking about: http://www.cs.utexas.edu/~mikebond/melt-oopsla-2008.pdf
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Hi,
On Wed, Apr 7, 2010 at 9:04 AM, Stéphane Ducasse <[hidden email]> wrote: >> Potato is JSqueak. I don't get it. > > I know :) > Now having two different repositories with not synchronized code is not really good. which two repositories? Best, Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
the one of potataoe and the code that we can find on Jsqueak web site.
I imagine that they are not the same. On Apr 7, 2010, at 3:37 PM, Michael Haupt wrote: > Hi, > > On Wed, Apr 7, 2010 at 9:04 AM, Stéphane Ducasse > <[hidden email]> wrote: >>> Potato is JSqueak. I don't get it. >> >> I know :) >> Now having two different repositories with not synchronized code is not really good. > > which two repositories? > > Best, > > Michael > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi Stéphane,
On Wed, Apr 7, 2010 at 3:45 PM, Stéphane Ducasse <[hidden email]> wrote: > the one of potataoe and the code that we can find on Jsqueak web site. > I imagine that they are not the same. they are not. As far as I understood it, the code available from the JSqueak page is JSqueak as originally released by Dan, and is not further developed, while the Potato SourceForge page and repository represent ongoing (well, as far as it goes with the manpower available) development. Best, Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I know and this is why I mentioned to dan that it would be good to merge back because may be a poor
guy will just reimplement exactly what the guy in potatoes already did long time ago. But at the end of the day I do not care because I know. I should stop to be altruist. Stef On Apr 7, 2010, at 4:45 PM, Michael Haupt wrote: > Hi Stéphane, > > On Wed, Apr 7, 2010 at 3:45 PM, Stéphane Ducasse > <[hidden email]> wrote: >> the one of potataoe and the code that we can find on Jsqueak web site. >> I imagine that they are not the same. > > they are not. As far as I understood it, the code available from the > JSqueak page is JSqueak as originally released by Dan, and is not > further developed, while the Potato SourceForge page and repository > represent ongoing (well, as far as it goes with the manpower > available) development. > > Best, > > Michael > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |