motoko (moc)

• Breaking change: the persistent keyword is now required on actors and actor classes (#5320, #5298).
  This is a transitional restriction to force users to declare transient declarations as transient and actor/actor classes as persistent.
  New error messages and warnings will iteratively guide you to insert transient and persistent as required, after which any stable keywords can be removed. Use the force.

  In the near future, the persistent keyword will be made optional again, and let and var declarations within actor and actor classes will be stable (by default) unless declared transient, inverting the previous default for non-persistent actors.
  The goal of this song and dance is to always default actor declarations to stable unless declared transient and make the persistent keyword redundant.

• Breaking change: enhanced orthogonal persistence is now the default compilation mode for moc (#5305).
  Flag --enhanced-orthogonal-persistence is on by default.
  Users not willing or able to migrate their code can opt in to the behavior of moc prior to this release with the new flag --legacy-persistence.
  Flag --legacy-persistence is required to select the legacy --copying-gc (the previous default), --compacting-gc, or generational-gc.

  As a safeguard, to protect users from unwittingly, and irreversibly, upgrading from legacy to enhanced orthogonal persistence, such upgrades will fail unless the new code is compiled with flag --enhanced-orthogonal-persistence explicitly set.
  New projects should not require the flag at all (#5308) and will simply adopt enhanced mode.

  To recap, enhanced orthogonal persistence implements scalable and efficient orthogonal persistence (stable variables) for Motoko:

  • The Wasm main memory (heap) is retained on upgrade with new program versions directly picking up this state.
  • The Wasm main memory has been extended to 64-bit to scale as large as stable memory in the future.
  • The runtime system checks that data changes of new program versions are compatible with the old state.

  Implications:

  • Upgrades become extremely fast, only depending on the number of types, not on the number of heap objects.
  • Upgrades will no longer hit the IC instruction limit, even for maximum heap usage.
  • The change to 64-bit increases the memory demand on the heap, in worst case by a factor of two.
  • For step-wise release handling, the IC initially only offers a limited capacity of the 64-bit space (e.g. 4GB or 6GB), that will be gradually increased in future to the capacity of stable memory.
  • There is moderate performance regression of around 10% for normal execution due to combined related features (precise tagging, change to incremental GC, and handling of compile-time-known data).
  • The garbage collector is fixed to incremental GC and cannot be chosen.
  • Float.format(#hex prec, x) is no longer supported (expected to be very rarely used in practice).
  • The debug print format of NaN changes (originally nan).

• Fixed file indices in the DWARF encoding of the debug_line section. This change is only relevant when using the -g flag (#5281).

• Improved large array behavior under the incremental GC (#5314)