>From the 90's there is the work of Ole Agesen, using type inference to detect (not) dead code and build SELF images.
http://dblp.uni-trier.de/pers/hd/a/Agesen:Ole In any case, I only wanted to say that it is unfair to say that Pharo is big when "you only load your packages". And I feel that's not true, if you're using the graphical environment, you need display, bitblt, morphic, widgets. As soon as you need to dynamically run scripts you need the compiler and parsing machinery. As soon as you write any program you mostly need many core libraries (just think about collections). How much space would take both in disk and in memory to build a similar environment in Java/Python? What I feel the most unfair is that we don't even take the time to measure to make a comparison. It's just a complaint... Now, I understand we could build images without development tools, but for that there is some work needed (not only from the pharo side but also from the developer's point of view). In the file server you can download latest minimal images both 32 and 64 bits (http://files.pharo.org/image/70/): - Pharo-metacello-7.0.0-alpha.build.654.sha.494bbfc.arch.32bit.zip <http://files.pharo.org/image/70/Pharo-metacello-7.0.0-alpha.build.654.sha.494bbfc.arch.32bit.zip>2018-03-06 10:314.4 MB <http://files.pharo.org/image/70/Pharo-metacello-7.0.0-alpha.build.654.sha.494bbfc.arch.32bit.zip> - Pharo-metacello-7.0.0-alpha.build.654.sha.494bbfc.arch.64bit.zip <http://files.pharo.org/image/70/Pharo-metacello-7.0.0-alpha.build.654.sha.494bbfc.arch.64bit.zip>2018-03-06 10:314.5 MB <http://files.pharo.org/image/70/Pharo-metacello-7.0.0-alpha.build.654.sha.494bbfc.arch.64bit.zip> Those are ~4.5M zip files containing 10MB images and 9MB changes files. Probably that is small enough for you. We can do better but each line of code we remove is indeed a lot of work. Those images have the following packages installed only: - Language Kernel + Traits + Class builder + Slots - RPackage - FFI Kernel - Opal Compiler + AST + Chunk files reader writers - Announcements - Collections - Colors - Files - Others (Hermes, Jobs, Transcript, System packages, UIManager...) - Zinc Character encoders and Buffered streams - Network - Monticello - Metacello + Filetree For a more detailed list, you can browse BaselineOfPharoBootstrap. If you want an image that requires packages that are not there (like morphic), you should install them on top and specify those as dependencies of your project. That is what we do with the Pharo IDE. Take a look at BaselineOfIDE. Again, this could be enhanced and we will greatfully accept any contribution, or discuss on skype about the details or help people to get into this. Guille On Tue, Mar 6, 2018 at 11:14 AM, Marcus Denker <marcus.den...@inria.fr> wrote: > Maybe this: > > https://rmod.inria.fr/web/publications/bib?query=Poli17c&display=abstract > > Guillermo Polito, Luc Fabresse, Noury Bouraqadi, and Stéphane Ducasse. > Run-Fail-Grow: Creating Tailored Object-Oriented Runtimes > > Producing a small deployment version of an application is a challenge > because static abstractions such as packages cannot anticipate the use of > their parts at runtime. Thus, an application often occupies more memory > than actually needed. Tailoring is one of the main solutions to this > problem i.e., extracting used code units such as classes and methods of an > application. However, existing tailoring techniques are mostly based on > static type annotations. These techniques cannot efficiently tailor > applications in all their extent (e.g., runtime object graphs and metadata) > nor be used in the context of dynamically-typed languages. We propose a > run-fail-grow technique to tailor applications using their runtime > execution. Run-fail-grow launches (a) a reference application containing > the original application to tailor and (b) a nurtured application > containing only a seed with a minimal set of code units the user wants to > ensure in the final application. The nurtured application is executed, > failing when it founds missing objects, classes or methods. On failure, the > necessary elements are installed into the nurtured application from the > reference one, and the execution resumes. The nurtured application is > executed until it finishes, or until the developer explicitly finishes it, > for example in the case of a web application. resulting in an object memory > (i.e., a heap) with only objects, classes and methods required to execute > the application. To validate our approach we implemented a tool based on > Virtual Machine modifications, namely Tornado. Tornado succeeds to create > very small memory footprint versions of applications e.g., a simple > object-oriented heap of 11kb. We show how tailoring works on application > code, base and third-party libraries even supporting human interaction with > user G. interfaces. These experiments show memory savings ranging from 95\% > to 99\%. > > > > > yes, Mariano Peck made a PhD on that (when we were exploring “how to get > smaller images” possibilities). > > We finally went for bootstrap, but we made an analysis on all > possibilities around. > > > > Mariano was doing swapping out… > > Mariano Martinez Peck, Noury Bouraqadi, Marcus Denker, Stéphane Ducasse, > and Luc Fabresse. Marea: An Efficient Application-Level Object Graph > Swapper. > > Abstract > Abstract During the execution of object-oriented applications, several > millions of objects are created, used and then collected if they are not > referenced. Problems appear when objects are unused but cannot be > garbage-collected because they are still referenced from other objects. > This is an issue because those objects waste primary memory and > applications use more primary memory than they actually need. We claim that > relying on the operating system's (OS) virtual memory is not always enough > since it cannot take into account the domain and structure of applications. > At the same time, applications have no easy way to parametrize nor > cooperate with memory management. In this paper, we present Marea, an > efficient application-level object graph swapper for object-oriented > programming languages. Its main goal is to offer the programmer a novel > solution to handle application-level memory. Developers can instruct our > system to release primary memory by swapping out unused yet referenced > objects to secondary memory. Our approach has been qualitatively and > quantitatively validated. Our experiments and benchmarks on real-world > applications show that Marea can reduce the memory footprint between 23\% > and 36\%. > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
