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. > > 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 at http://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
