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 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 >
