Hi Chris,


> On Jul 13, 2016, at 9:40 AM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> I thought "6.0" was planned to be the 64-bit version of "5.1", and 5.1
> the 32-bit version of the same image contents...

That's not what I tried to articulate at all.  What I want for 5.1 is essentially what Marcel outlines below, a cleaned up 5.0 with 64-bit support.

For 6.0 I'm hoping we will do

- the Sista bytecode set (with backwards compatibility support for the existing set).  This gives us 32k literals, 
- FullBlockClosure, which means I depended method objects for blocks, and hence (slightly) faster block activation
- read-only objects and hence read-only literals

These three provide the necessary support for the image-level Scorch adaptive optimiser.  This will be demonstrated at ESUG in Prague and productized by next year

- collapsing of ContextPart and MethodContext onto Context.  The closure model does not need BlockContext so this is a nice simplification, one that Pharo has already released.

Revised finalization.  Spur supports ephemerons which allow pre-mortem finalisation (they identify objects about to die, not the death of objects) and allow cycle-free addition of dependencies (which is how they identify objects about to die).  Since individual ephemerons must be identified (those whose keys are about to die) there is a finalisation queue into which the GC places such ephemerons. Spur also enqueues weak arrays that have lost efferent on the same queue.  Hence we can profitably reimplement many finalisation facilities:
- the current scheme has the VM signal a semaphore in any GC cycle that collects one or more referents of one or more weak arrays, and weak arrays are held in registries.  hence to finalise a single weak array requires finalising any and all weak arrays in the registries.  Instead, weak arrays can hold onto a manager directly through an inst var and have this object do the work, now meaning that only those weak arrays that lose references do work in each GC cycle.
- DependentsFields can be reimplemented to use a non-finalising ephemeron to attach dependents to objects without preventing their GC (unlike the current weak array approach)
- pre-mortem finalisation allows files to auto-finalise, hence flushing their contents before closing instead of finalising a copy which merely closes the file descriptor
- exiting the image should be arguably be done only after running a full GC and then draining the finalisation queue, and hence arguably there may need to be an emergency exit

All of these together will impact code, breaking some old code, but always in simply fixable ways, and provide new facilities and pave the way to a substantial performance increase with Sista.  Hence these changes need IMO to be a full release, not a point release.

>> On Wed, Jul 13, 2016 at 4:17 AM, Herbert König <herbertkoenig at gmx.net> wrote:
>> Really exciting news!
>> 
>> Herbert
>> 
>> 
>> -------- Ursprüngliche Nachricht --------
>> Von: "marcel.taeumel"
>> Datum:13.07.2016 10:29 (GMT+01:00)
>> An: squeak-dev at lists.squeakfoundation.org
>> Betreff: [squeak-dev] [ANN] The Squeak 5.1 Release Plan
>> 
>> Hey, there.
>> 
>> I just want to inform all of you that we are in the middle of preparing the
>> next Squeak 5.1 release. We are working on automation for
>> generating/updating all release artifacts so that we are eventually able to
>> shorten our release cycle in the future. For this, we are using smalltalkCI
>> (thanks Fabio!), TravisCI, and AppVeyor.
>> 
>> Here are the important dates:
>> * Feature Freeze on July 31, 23:59 AOE
>> * Code Freeze on August 14, 23:59 AOE
>> * Release between August 15 and 19
>> 
>> As these dates suggest, our goal is to have the release before this year's
>> ESUG. However, there is another important Smalltalk-related event this year:
>> 20 years of Squeak. :-) Yeah! It was around October 1996, when the first
>> Squeak came into the world. ...having its own worlds. :D So, it would only
>> make sense to also have a special release for this birthday. For this, we
>> revived all of the cool multimedia content, known from Squeak 1 through
>> Squeak 3, and made it fit for the current Squeak code base. Oh, this is so
>> exciting. :-)
>> 
>> Anyway, what's with Squeak 5.1 and 64-bit? Since the release of Squeak 5.0,
>> we've been working hard and made a lot of bug fixes and added some features
>> to improve the overall usability and robustness of the Squeak live
>> programming system. Meanwhile, the VMs improved as well. Cog's object format
>> "Spur" got more robust, the JIT improved, and the whole code base moved from
>> SVN to Git: https://github.com/OpenSmalltalk/opensmalltalk-vm.
>> 
>> Still, what's up with 64-bit? We have working 64-bit VMs for Mac OS X and
>> Linux. Hence, we will take the chance and also release 64-bit bundles for
>> Squeak 5.1. Be informed that this means a new .image file. You cannot open a
>> 64-bit .image with a 32-bit VM and vice versa. This, however, is nothing
>> serious because we are working on an updated version of our SystemTracer to
>> convert back and forth. With limitations, of course. ;-) You cannot fill a
>> bottle of beer into a shot glass.
>> 
>> What's up with the All-in-one? There will be the usual 32-bit all-in-one
>> package, which combines VMs for Linux, Mac OS X, and Windows. Since there
>> will be no 64-bit Windows VM within the next two months, we refrain from
>> creating an almost-all-in-one-32/64 package. This would only confuse the
>> users. In the future, we can arguably expand the concept of the All-in-one
>> to also contain 32-bit and 64-bit VMs and images.
>> 
>> So, what are the prospective release artifacts for Squeak 5.1?
>> * All-in-one (Linux/Mac/Win) 32-bit
>> * Mac OS X App 32-bit, signed
>> * Mac OS X App 64-bit, signed
>> * Linux Bundle 32-bit
>> * Linux Bundle 64-bit
>> * Windows App (maybe with MSI Installer) 32-bit, maybe signed
>> * ZIP archive containing .image and .changes, no VM, no .sources
>> 
>> We plan to also use the new release automation process for Squeak 5.0 and
>> update those release artifacts as well. We will update our squeak.org
>> Website but you will always find the artifacts on
>> http://files.squeak.org/5.0 and http://files.squeak.org/5.1 .
>> 
>> :-)
>> 
>> Best,
>> Marcel
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://forum.world.st/ANN-The-Squeak-5-1-Release-Plan-tp4906439.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>