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