1. GemStone/S 64 Bit 3.3.5 Release Notes
Overview
GemStone/S 64 Bit 3.3.5 is a new version of the GemStone/S 64 Bit object server. This release fixes a number of bugs, and adds support for Solaris/x86 v11.3.
These release notes describe changes between the previous version of GemStone/S 64 Bit, version 3.3.4, and version 3.3.5. If you are upgrading from a version prior to 3.3.4, review the release notes for each intermediate release to see the full set of changes.
For details about installing GemStone/S 64 Bit 3.3.5 or upgrading from earlier versions of GemStone/S 64 Bit, see the GemStone/S 64 Bit Installation Guide for v3.3.5 for your platform.
Supported Platforms
Platforms for Version 3.3.5
GemStone/S 64 Bit version 3.3.5 is supported on the following platforms:
- Solaris 10 and 11 on SPARC
- Solaris 10 and 11.3 on x86
- AIX 6.1 on POWER6 and POWER7 and AIX 7.1 on POWER7 and POWER8
-
Red Hat Enterprise Linux Server 6.4, 6.5, 6.7, and 7.1;
Ubuntu 14.04 and 16.04; and SUSE Linux Enterprise 12, all on x86 -
OS X 10.9.5 (Mavericks) with Darwin 13.4.0 kernel, and OS X 10.11.2 (El Capitan)
with Darwin 15.2.0 kernel, on x86 (Mac is supported for development only)
Supported Windows client platforms are
Note that Solaris/SPARC support is being deprecated and will be available for development only. Solaris on x86 will continue to be fully supported.
For more information and detailed requirements for each supported platforms, please refer to the GemStone/S 64 Bit v3.3.5 Installation Guide for that platform.
GemBuilder for Smalltalk (GBS) Versions
The following versions of GBS are certified with GemStone/S 64 Bit version 3.3.5:
GBS version 8.2
GBS version 8.1
GBS version 5.4.3
For more details on supported GBS and client Smalltalk platforms and requirements, see the GemBuilder for Smalltalk Installation Guide for that version of GBS. Consult the matrices on the website, gemtalksystems.com/products/gbs-vw or gemtalksystems.com/products/gbs-va, for the latest updates.
VSD Version
The GemStone/S 64 Bit v3.3.5 distribution includes VSD version 5.3, the same version of VSD as v3.3.4. For details on VSD versions, see the documentation on the website at gemtalksystems.com/products/vsd/versions/.
Changes in this release
Simplified ICU library version handling
GemStone uses the open-source ICU libraries to support sophisticated handling of sorting and collation of strings containing Characters outside of the ASCII range. As the Unicode standard is updated and versioned, the ICU libraries are also versioned. This can impact GemStone structures that rely on unchanging collation order.
Rather than rebuilding these data structures, GemStone applications can safely continue to use the earlier version of the ICU libraries. New applications, that start with an empty repository, will use the ICU library that was current for that version.
When the ability to control the ICU version was introduced, in v.3.3.1, several global and environment variables were introduced to ensure that repositories did not inadvertently mix up ICU versions. This created some complexity during upgrade and restore from backup.
This has been simplified for version 3.3.5.
- The configuration parameter STN_GEM_LIBICU_VERSION and the environment variable $GS_LIB_ICU_VERSION have been removed and are ignored if present. $GS_LIB_ICU_BYPASS has also been removed and is no longer needed.
- The value of (Globals at: #IcuLibraryVersion) in the repository now controls which version of the ICU library is loaded during login.
- There is now no special processing required during upgrade from earlier GemStone/S 64 Bit versions.
- During restore from full backup, you do not need to do any special handling for a discrepancy between the clean extent and the restored version. However, after performing the restore in a linked session, topaz will have the clean extent’s ICU libraries loaded, so you may need to exit topaz and restart to restore transaction logs or commit the restore.
- To upgrade the ICU library version, you must execute
Globals at: #IcuLibraryVersion put: aValue
where aValue is either '54.1' or '51.2'.
This should only be changed by SystemUser when no other sessions are logged in, and you must shut down and restart the stone, and then ensure that all SortedCollections, indexes, and other structures that depend on collation are rebuilt.
Applications progressively upgraded through 3.3 or any 3.1.x version
Unicode-collation based data structures created in any 3.1.x version may be collated according to ICU v48.1. After upgrading, there will be a sort order mismatch, with a small risk of incorrect lookups. This is true for applications that were subsequently upgraded to 3.2.x or 3.3.x. It is recommended that all applications that used unicode comparisons in persistent data structures in 3.1.x examine all data structure and resort and rebuild.
Applications that upgraded specifically to v3.3, not to a later 3.3.x version, may also have a mismatch, as this version loaded the incorrect ICU library version for upgraded repositories.
Special issues for ICU libraries on AIX
Note the automated handling of ICU library loading and simplified process does not apply to applications on AIX. AIX does not support deferred binding of shared libraries; using older ICU library versions requires changing the library names by creating symbolic links, and/or manually setting the IcuLibraryVersion value before upgrade.
If you are using unicode comparisons on AIX and are upgrading, contact GemTalk Technical Support to determine the appropriate actions.
Bugs Fixed
Remote shared cache shutdown
When there is a stuck read in progress, due (for example) to a Gem death, the remote cache may get stuck in removing pages from the cache and be unable to recover. This prevents the cache from shutting down, including when the stone itself is shut down.(#46821)
This is related to the issue for bug #46708, which was fixed in v3.3.4.
Split IdentitySet store traversal may encounter oop not allocated error
If you do a store traversal of an IdentitySet, and the report is split across traversal buffers so that the first report in a buffer starts with one of the private named instvars that is not the first instvar, the server reports the error GbsObjErrOopNotAllocated. (#46822)