Hi Esteban,
On Fri, Jun 13, 2014 at 6:31 AM, Esteban Lorenzano <[email protected]> wrote: > > On 13 Jun 2014, at 06:44, Esteban Lorenzano <[email protected]> wrote: > > > On 13 Jun 2014, at 04:29, Eliot Miranda <[email protected]> wrote: > > > > On Thu, Jun 12, 2014 at 10:48 PM, stepharo <[email protected]> wrote: > >> Thanks eliot. >> As soon as it is available for Pharo we will try with some large moose >> images. >> > > OK, but just so you know I'm not going to do the Pharo bootstrap. I hope > someone in your team will have a go. I'm happy to help but I don't know > Pharo well enough to do this. It's a matter of making sure the Monticelo > packages can be edited. The Squeak code may just work but I wouldn't know. > > > yes, I’m on it :) > > > I’m already building the PharoVM with Spur :) > but that’s just the beginning… I need to make it NB compatible first (a > small step, I will finish today or tomorrow) > and I need to convert the images… that will take more time (and I will > need some help… cough, cough, Camille, cough, cough, Guille) :P > let me know if I can help... I'm curious whether the basic image bootstrap works out-of-the-box or not (SpurBootstrap bootstrapImage: 'imageBasename'). Yesterday I wrote scripts to automate the Squeak process, and these were used to produce the Squeak trunk Spur image, see http://www.squeakvm.org/svn/squeak/branches/Cog/image/ buildspurtrunkimage.sh BuildSqueakTrunkImage.st WriteSpurPackagesToTempDir.st LoadSpurPackagesFromTempDir.st Most of this is scripting the Monticello package patch and load. Esteban > > > Esteban > > > >> >> Stef >> >> >> On 13/6/14 01:41, Eliot Miranda wrote: >> >>> Hi All, >>> >>> it gives me great pleasure to let you know that a spur-format trunk >>> Squeak image is finally available athttp://www.mirandabanda.org/ >>> files/Cog/SpurImages/. Spur VMs are available at >>> http://www.mirandabanda.org/files/Cog/VM/VM.r2987/. >>> >>> Spur is a new object representation and garbage collector for >>> Squeak/Pharo/Croquet/Newspeak. >>> >>> Features >>> The object representation is significantly simpler than the existing >>> one, and hence permits a lot of JIT optimizations, in particular allocating >>> objects in machine code. This speeds up new, new: et al, but also speeds >>> up blocks because contexts and closures are now allocated in machine code. >>> It also provides immediate characters, so for example accessing wide >>> strings is much faster in Spur, since characters do not have to be >>> instantiated to represent characters with codes greater than 255. >>> >>> The garbage collector has a scavenger and a global scan-mark-compact >>> collector. The scavenger is significantly faster than the existing >>> pointer-reversal scan-mark-compact, hence GC performance is much improved. >>> >>> The memory manager manages old space as a sequence of segments, as >>> opposed to the single contiguous space provided by the existing memory >>> manager. The memory manager grows the heap a segment at a time, and can >>> and will release empty segments back to the host OS after a full GC. Hence >>> Spur is able to grow the heap to the limit of available memory without one >>> having to specify the VM's memory size at start-up. >>> >>> The object representation uses "lazy forwarding" to implement become:, >>> creating copies of objects that are becommed, and forwarding the existing >>> objects to the copies. While Spur still scans the stack zone on become to >>> ensure no forwarding pointers to the receiver exist in stack frames (for >>> check-free push and store instance variable operations), it does not scan >>> the entire heap, catching sends to forwarded objects as part of the normal >>> message send class checks, hence following forwarding pointers lazily, and >>> eliminating forwarders during GC. The existing memory manager does a full >>> memory sweep and compact to implement become. Hence Spur provides the >>> performance advantages of direct pointers while providing a significantly >>> faster become. >>> >>> While Spur uses moving GC (scavenging and compaction on full GC), just >>> like the existing memory manager, Spur supports pinning, the ability to >>> stop an object from moving. Old space objects will not be moved if pinned. >>> Attempting to pin a new space object causes a become, forwarding the new >>> space object to a pinned copy in old space. This allows simpler >>> interfacing with foreign code through the FFI, since one can hand out >>> references to pinned objects in the knowledge that they will not be moved >>> by the GC. >>> >>> Finally Spur supports ephemerons in a simple and direct way, providing >>> pre-mortem per-instance finalization. Although the image-level support >>> needs to be written, it should soon be possible to improve the finalization >>> of entities such as buffered files (ensuring they are flushed before being >>> GCed), etc. >>> >>> >>> Future Work >>> Spur is as yet a work in progress. The 32-bit implementation is usable >>> and appears stable. The major missing component is an incremental >>> scan-mark GC that should eliminate long pauses due to the global >>> scan-mark-compact GC (which is still invoked at snapshot time). I hope to >>> start on this soon. But another key facet of Spur is that the object >>> header format and the sizes of objects are common between 32- and 64-bits. >>> In 32-bit and 64-bit Spur, object bodies are multiples of 8 bytes, so >>> there may be an unused slot at the end of a 32-bit object with an odd >>> number of slots. Hence Spur is close to providing a "true" 64-bit system, >>> one with 61-bit SmallIntegers, and 61-bit SmallFloats (objects with the >>> same precision, but less range that 64-bit Float, done by stealing bits >>> from the exponent field). I look forward to collaborating with Esteban >>> Lorenzano on 64-bit Spur and hope that it will be available early next year. >>> >>> >>> Experience >>> I am of course interested in reports of performance effects. Under >>> certain, hopefully rare circumstances, Spur may actually be slower (one is >>> when the number of processes involved in process switching exceeds the >>> number of stack pages in the stack zone). But my limited experience is >>> that Spur is significantly faster than the existing VM. Please post >>> experiences, both positive and negative. >>> >>> Finally, caveat emptor! This is alpha code. Bugs may result in image >>> corruption. If you do use Spur, please try and back up your work just in >>> case. And if anything does go wrong please let me know, preferrably >>> providing a reproducible case. >>> >>> >>> Enjoy! >>> Eliot Miranda >>> >> >> >> > > > -- > best, > Eliot > > > > -- best, Eliot
