Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Magma 1.5 Release Notes
Last updated at 3:46 am UTC on 18 August 2015
Version 1.5 of Magma coincides with the release of Squeak 5, as well as many other improvements and fixes over Magma 1.4.

Transparent Cog and Spur Compatibility

Magma 1.5 is transparently compatible with Spur's new object memory format and VM. Persistent CompiledMethod headers are transparently converted back-and-forth as necessary depending on what kind of client (a V4 Cog or V5 Spur) is accessing.

Under Cog, the server can only grow to about 1.8GB before running out of memory and once it grows that large, it never gives that memory back to the OS. Using the aforementioned multicore batch processing capability, I was able to increase the number of simultaneous forked clients so that the server could grow to nearly to 4GB! Once the large task was completed and clients signed out, the server actually recovered the memory and went back down to consuming only about 60MB from the OS. Magma thrives on the extra speed and memory management and breathing-room provided by Spur.

A New Concurrent Statistical Accumulator Type

A MagmaCounter is a legacy Magma type which allows multiple clients to commit deltas to a synchronized accumulator. 1.5 introduces MagmaStat, an extension to MagmaCounter adds a synchronized #sum, #min, #max and #last. This was created to support a multidimensional data-aggregator. It allows multiple clients to simultaneously accumulate into a single accumulator, without commit-conflict, and the accumulator will always report the latest known values.

New Object-Level Meta Information

Meta-information can now be retrieved for any object as long as the commit-log file in which it was committed is still available to the database. Since these files are not explicitly required to be kept (it depends on ones backup and roll-forward needs), so it depends on your server administration.


If the commit-log record is no longer available, nil will be answered for all of the above (except magmaOid and isDirtyInMagma, of course). Each Sessions #definition can now answer the collection of persistent #classes in the DB. #dirtyGraphDo: allows all currently dirty objects to be enumerated.

Experimental Multicore Batch Processing Tool

A new tool employs the client-server framework in a new way – to manage batch processing tasks using multiple CPU cores. The user creates a collection of Blocks which are then forked and run concurrently in their own separate VM process. The user specifies how many CPU cores to allocate to the task so that the framework will maintain exactly that many processes running concurrently. If 100 blocks of work are created but only a 4-core processor, then only 4 at a time will run, but as any block finishes and exits its image, the framework automatically detects this and replace that slot by the launch of the next block, in sequence, until all the blocks are done. The number of cores can adjusted dynamically after the process has started.

Although Ma Client Server framework is a standalone framework (completely independent of Magma), typical usage of this multi-core feature is for each forked block to collaborate on the same Magma database(s). A variety of configurations are possible supporting several use-cases. The client-sever framework provides the inter-proces communication between the calling process and the forked block processes to support supervisory use-cases (remote progress bars) over all of the forked processes from the single launching image, with pause, resume, etc.).

A New Data-Repair Tool

MagmaDataRepair is used to perform schema upgrades or other "repairs" on Magma models in a controlled and reliable fashion. It can take advantage of the multi-core processing, if necessary.
This is a great tool, the user simply creates the first-class MagmaDataRepair object using the #at:start:enumerate:check:repair: constructor message. A MagmaDataRepair instance is returned which supports the API of the repair:

Graphical Status Monitor

Magma has kept track of various timings and counts of its operations for years. The objects are in there, but not easily viewed until now. Some rudimentary charts show various stats by 5-minute periods over the last 24 hours (configurable). This can provide insight into, for example, the number and size of reads vs. commits by an application, which might be interesting for, i.e., application performance tuning.

Better Linux Server Integration


Performance and Robustness


Local-Conflict Detection

At last, Magma will now detect a local-conflict when a session must reconnect and catch-up to the repository. During this process, if any objects are refreshed which were already locally changed by that session, a MagmaTooFarBehindConflict is signaled.
The idea is it can be handled the same as a commit-conflict, because the new MagmaTooFarBehindConflict inherits the 'result', a FailedCommitResult.

Compatibility Notes

FloatIndex was revamped so that negatives are treated properly as less than positives in their indexing sequence. Any applications using FloatIndex should rebuild them.