1. GemStone/S 64 Bit 3.5.1 Release Notes

Platforms for Version 3.5.1

GemStone/S 64 Bit version 3.5.1 is supported on the following platforms:

• Red Hat Enterprise Linux Server 6.9 and 7.4, and
  Ubuntu 16.04 and 18.04, and SUSE Linux Enterprise 12, on x86.
  Testing has been done on some earlier Red Hat Enterprise Linux Server 6.x and 7.x versions with the latest security patches.
• Solaris 10 and 11.4 on x86
• AIX 6.1, 7.1, and 7.2
• OS X 10.14.3 (Mojave), with Darwin 18.2.0 kernel, on x86
  (Mac is supported for development only)

For more information and detailed requirements for each supported platforms, please refer to the GemStone/S 64 Bit v3.5.1 Installation Guide for that platform.

GemBuilder for Smalltalk (GBS) Versions

GemStone/S 64 Bit version 3.5.1 requires GBS version 8.4 or later for VisualWorks Smalltalk, or version 5.4.5 or later for VA Smalltalk.

The following versions of GBS are supported with GemStone/S 64 Bit version 3.5.1:

VSD Version

The GemStone/S 64 Bit v3.5.1 distribution includes VSD version 5.4.2. The previous version of GemStone/S, v3.5, included VSD v5.4.

VSD version 5.4.2 is a maintenance release, includes a few bug fixes and new cache statistics definitions for v3.5.1. For details on the changes, see the Release Notes for VSD v5.4.2.

VSD versions are not tied to GemStone server versions: both older and newer versions of VSD can be used to read statmonitor files generated by both older and newer versions of GemStone/S and GemStone/S 64 Bit.

Upgrade

There have been changes in the linking process for Linux and Solaris, and in the login API for the thread safe GCI (gcits.hf).

User actions will need to be relinked, and source code using the thread-safe API will need to be updated and recompiled.

Documentation

In addition to the updated Installation Guides, an Installation guide is now provided for the Raspberry Pi Client. Note that the Raspberry Pi is not a supported configuration.

Updated library versions

• The version of lz4 has been updated to v1.9.2
• The version of openssl has been updated to v1.1.1d

Distribution change in packing libraries

In 3.5, slow and noop RPC shared libraries were added to the distribution, located in subdirectories of /lib. The linked libraries were also moved and renamed to remove the _slow or _noop; however, this caused load failures (gemnetobject_slow failed to load slow; ran fast libraries), and these libraries have been reverted to the previous names and locations.

Distribution change for Raspberry Pi

The experimental distribution of GemStone/S 64-Bit Raspberry Pi Client has updated directory names. For consistency with other GemStone products, the directories "bin" and "sys" are now "bin32" and "sys32". Only 32-bit Raspberry Pi Clients can be used with GemStone.

Recommendation to clear /opt/gemstone/locks/ on system restart

If there is an unexpected shutdown, the lock files (filename..LCK) for GemStone processes such as Stone and cache remain in the /opt/gemstone/locks/ directory (or on older systems, /usr/gemstone/locks/). These lock files include the PID and other information on the running process, that is used to determine process status.

On restart, it is possible for kernel processes to reuse this PID. If the owner is root, GemStone cannot reliably determine the status of the process and thus cannot safely delete the lock file. These lock files must be manually deleted.

It is recommended that systems be setup so that on boot, the lock files in /opt/gemstone/locks/*.LCK are deleted automatically on system restart.

Do not delete /opt/gemstone/locks/gemstone.hostid.

Support for transparent huge pages on Linux

GemStone supports explicit use of "large" pages (that is, 2 MB and/or 1GB huge pages), in addition to the default 4KB page size. These are large pages that permanently allocated by the kernel, and if configured, the GemStone configuration parameter SHR_PAGE_CACHE_LARGE_MEMORY_PAGE_POLICY manages their use.

In addition to these explicitly configured huge pages, the Linux kernel (in versions later than 2.6.38) supports transparent huge pages, which are 2MB in size (/sys/kernel/mm/transparent_hugepage/hpage_pmd_size returns 2097152). Transparent huge pages are limited to anonymous memory regions. If they are enabled (they are by default), transparent huge pages are managed by the kernel without application level configuration.

GemStone now can take advantage of transparent large pages for the shared memory region. GemStone now always mmaps in exact multiples of the transparent huge page size, and invokes madvise on the shared memory region.

Linux systems should ensure:

• /sys/kernel/mm/transparent_hugepage/enabled
  should be set to "always" or "madvise".
• /sys/kernel/mm/transparent_hugepage/defrag
  should be set to "always" or "madvise".
• /sys/kernel/mm/transparent_hugepage/shmem_enabled
  should be set to "madvise", "within_size", or "always".

To confirm these settings are correct in your linux environment, cat the file; the enabled parameter is within the square brackets. E.g.,

unix> cat /sys/kernel/mm/transparent_hugepage/enabled

always [madvise] never

To confirm that GemStone is using transparent huge pages, after GemStone has been started up, execute:

cat /proc/shrpcmonPid/smaps

and look for the /SYSV line, and the subsequent value for ShmemPmdMapped.

For example:

unix> cat /proc/shrpcmonPid/smaps

<snip>

7fa915a0000....						 /SYSV197f0019 (deleted)

Size:             124928 kB

KernelPageSize:        4 kB

MMUPageSize:           4 kB

<snip>

AnonHugePages:         0 kB

ShmemPmdMapped:   120832 kB

<snip>

Note that this command is expensive and should not be run unnecessarily.

Improved Shared Page Cache startup performance

The initialization of the Shared Page Cache (SPC) during Stone startup has been multithreaded. This provides a substantial performance improvement for Stone startup when the SPC is large.

Improvements in disk space usage after restore from full backup

GsBitmap added methods

The following methods have been added to GsBitmap, to allow more powerful repository-wide analysis of objects in the database.

GsBitmap >> allReferencedObjects
Similar to referencedObjects, returning a new instance of GsBitmap containing the objects directly referenced by the objects in the receiver; but in addition, the result includes all of the normally hidden interior nodes for large objects.

GsBitmap class >> allValidOops
Returns an instance of GsBitmap containing the oops of all valid objects in the repository. This bitmap only reflects currently committed objects that are not in the process of being garbage collected, i.e, not in the possible dead or deadNotReclaimed sets.

GsBitmap class >> transitiveReferences: aCollection
Returns an instance of GsBitmap that contains all the objects which are transitively referenced from the objects in aCollection.

GsBitmap class >> allTransitiveReferences: aCollection
Similar to transitiveReferences:, however the result includes all of the normally hidden interior nodes for large objects.

GsBitmap class >> allObjectsExcept: aCollection
Returns an instance of GsBitmap that contains all objects that exist which are not contained in the objects transitively referenced from aCollection. The objects in the result may or may not be live objects (reachable from the repository roots).

Reporting extents and files in GB or MB

The methods fileSizeReport and extentSizeReport, which report on the sizes of extent files in the repository, now report in units of GB if the repository total size is greater than 2GB.

To return results in MB as in previous releases, the following methods have been added:

Repository >> extentsReportMB 

Repository >> fileSizeReportMB

SymbolDictionary printString change

SymbolDictionaries, both those defined by GemStone base (such as Globals), and user-created SymbolDictionaries, may have names, which are keys within the SymbolDictionary that reference itself.

Previously, printing a SymbolDictionary always printed the entire contents. Now, if a name is found, only the name is displayed. If no name is found, as previously, the entire contents is displayed.

For example, the new display for Globals is:

topaz 1> exec Globals printString %

aSymbolDictionary( name: #'Globals' )

Improved reporting on transaction conflicts

When a transaction conflict occurs, the methods System >> conflictReportString and conflictReportString: can be called. These methods now include newlines, to make the output easier to read.

The following method has been added:

System class >> conflictReportString: conflicts maxOops: maxOops
The conflicts argument is the Array returned by System Class>>transactionConflicts. The report contains oops and class names for each object in conflict, limited to the first maxOops oops in each category of conflict.

System >> remoteCachesReport now includes Stone’s cache

The report returned from System class >> remoteCachesReport previously did not include the stone’s cache; this is now included in the report.

Added method

Time >> addMilliseconds: anInteger
Returns a Time that describes a time of day anInteger milliseconds later than that of the receiver.

objectAudit warnings on old 32-bit fanout in upgraded repositories

Repositories that were converted from 32-bit Gemstone/S and did not run postconv may have the older fanout, which may be less performant. This is reported as a warning by objectAudit. This warning did not respect the topaz push command, and was only visible in the console, and thus was not always found. (#48277)

The oops were written to hidden set 26, which was not easily loaded as a GsBitmap. Now, the oops are instead put into the ListInstances hidden set, which is easily accessible as a GsBitmap. (#48311)

The warning has also been reworded for clarity.

gslist output in json format

gslist has added the -j argument, which returns information about running GemStone processes comparable to the gslist -x output, in json format.

For example:

unix> gslist -j -n gs64stone

{"GemStoneServers":[

	{

	"Name":"gs64stone",

	"Host":"benton",

	"HostId":"69621bb0476b1937",

	"Ip":"10.94.141.15",

	"Status":"Exists",

	"Type":"Stone",

	"Version":"3.5.1",

	"Creator":"gsadmin",

	"Started":"2019-09-13T16:08:00.000-07:00",

	"Pid": 29010,

	"Port": 35043,

	"Options":{},

	"LogName":"/users/gsadmin/351/data/gs64stone.log",

	"Sysconf":"/users/gsadmin/351/data/system.conf",

	"Execonf":null,

	"GEMSTONE":"/users/gsadmin/351",

	"Exe":"/users/gsadmin/351/sys/stoned"

	}

]}

This can be easily processed as needed for system administration. For example:

(JsonParser new parse: (System performOnServer: 'gslist -j')

creates a structure of Dictionaries and Arrays in GemStone Smalltalk containing all information about all GemStone services.

Note that all keys and values in the output are capitalized. This includes gslist status values (such as ’Exists’), and command line arguments.

Return values for startnetldi, stopnetldi, startstone, stopstone

The utilities that start and stop the Stone and NetLDI have further changes in the process return values in this release, for cases that could be handled as either success or failure.

In versions prior to v3.5, cases in which an attempt was made to start a service that was already running, or to stop a service that was not running, returned 0 (success).

In version 3.5, the return value of these cases was modified to return 2 (warning). For v3.5.1, all return values have been reviewed and these cases have been updated again to return 1 (informational), to allow additional non-fatal error return values. These return values are documented in the -h help text for startstone, stopstone, startnetldi, and stopnetldi.

The following are the

startnetldi returns:

• 0 on successful start.
• 1 if the specified netldi is already running.
• 2 if already running but the executables have been deleted.
• 3 if an error occurred and the specified netldi was not started.

stopnetldi returns:

• 0 on successful stop.
• 1 if the specified netldi was not running.
• 3 if an error occurred and the specified netldi could not be stopped.

startstone returns:

• 0 on successful start.
• 1 if the specified stone is already running.
• 2 if already running but the executables have been deleted.
• 3 if an error occurred and the specified stone was not started.

stopstone returns:

• 0 on successful stop.
• 1 if the specified stone was not running.
• 3 or above, an error occurred and the specified stone could not be stopped. Values greater than 3 indicate specific kinds of errors.

In general, GemStone processes return 1 for Informational, 2 for warning, and 3 and above for error cases.

stopnetldi by root user on any NetLDI

If stopnetldi is run as the root user, it will now stop any running NetLDI, including NetLDIs that are not running as root.

Disallowed to startstone with an extent of a later version

Executing startstone requires that the extent files be of the same version as the startstone executable, or an earlier version in the case of upgrade.

It is now explicitly disallowed to startstone with extents that are of a later version than the startstone executable. (#48209)

copydbf -i/-I of extent file now includes version

A line has been added to the copydbf -i/-I output for an extent file, providing the version number of the extent.

Applications running without $GEMSTONE

Further support has been added to allow GemStone clients to run without the $GEMSTONE environment variable.

To login from linked or RPC topaz clients, you must have the bin directory of the GemStone installation on the machine search path, and specify the full path to the topaz executable.

Running without $GEMSTONE may be particularly useful for running topaz solo scripting.

For example, without GEMSTONE set, the following will start a topaz solo session and execute the script mySoloScript.

unix> export PATH=$PATH:/gemstoneInstallDir/bin 

unix> gemstoneInstallDir/bin/topaz -l -q -C 'GEM_SOLO_EXTENT=gemstoneInstallDir/bin/extent0.dbf;' -S mySoloScript

Similarly, GCI application using GemBuilder for C can run without the $GEMSTONE environment variable, provided all the required GemStone libraries are located in the same directory as the executable containing the main() function of the GCI application.

topaz -S option

The -S topazcommandfile option was added in v3.5, to support scripting with topaz.

topaz now handles BOM input correctly

When a text file begins with a BOM (Byte Order Mark) character, this indicates the encoding of the file. topaz now uses the UTF-8 BOM character to interpret the file as UTF-8, regardless of the current fileformat setting. If there is no UTF-8 BOM character at the beginning of the file, topaz continues to use the fileformat setting to interpret the file.

topaz does not support UTF-16 or UTF-32, so attempting to read a file with the these BOM characters is an error. In v3.5, this error would crash topaz (#48198)

Log file locations changes for remote login processes

GemStone/S 64 Bit v3.5 included some changes in the calculation of log file locations for process logs, both Gem logs and the logs for remote processes. These changes included

• an additional function for the startnetldi -D flag, to provide a default directory for log files, in the absence of #dir: or absolute-path #log: directives.
• using the -D argument to determine directories for files forked by each NetLDI, to ensure that in a distributed configuration with different file access, each NetLDI could be individually configured with log files directory locations that are valid on that node.

These changes introduced some incorrect behavior (see Remote process support logs may not be written to intended location). These issues have been fixed, and the code and log file locations have been reviewed and tested.

Attaching to a running Gem for debugging

It is now possible to set up a Gem to execute code that will be debugged, and attach to this running gem from topaz or another process.

To do this, the Gem must be configured to start a separate thread in the VM that listens for the command to connect. This can be done in two ways.

• Before login, set the configuration parameter GEM_LISTEN_FOR_DEBUG = true;. With this defined, during login the Gem will will print a line to the stdout (the linked console or gem log file):

Listening for debug: DEBUGGEM pid random32BitDebugToken

• By invoking the new method System class>>listenForDebugConnection. This method returns the random32BitDebugToken. token (a random 32-bit integer), that is an argument to the call to attach. To get the PID of the gem, which is also required for login, invoke System class >> gemProcessId.

Then, a topaz or GCI application (the debugging session) makes the calls to connect, specifying both the PID of the executing Gem session, and the token.

topaz 1> DEBUGGEM pid random32BitDebugToken

successful attach

topaz 2> 

If the connection is successful, the debugging session will have debugging control over the executing session.

• If a Smalltalk call is in progress, the equivalent of a soft break occurs in the executing Gem, and the debugging gem can examine the stack. Operations that modify the stack, such as STEP are disallowed, and the debugging session cannot commit.
• If execution is not in progress, the debugging gem takes control and further operations in the executing session are blocked.
• If a fetch or store traversal is in progress, the debugging session will get control after this completed.

Either a LOGOUT or CONTINUE in the debugging session will close that session and allow the executing session to continue.

(BoolType) GciDebugConnectToGem(

    int gemPid

    );

(BoolType) GciDebugStartDebugService(

    uint64 debugToken

    );

Other topaz changes

The following sub/commands have been added:

FR_1
Similar to FRAME, but displays stack temps one per line in the frame.

stack set aGsProcess
Takes one argument an object specification that resolves to a GsProcess, and make that GsProcess the currently active stack for debugging.

Other Changes in Configuration Parameters

set gemnetid 'gemnetobject -e nosuch.file.conf -C CONFIG_WARNINGS_FATAL=TRUE'

GEM_ENV=GEMSTONE_KEEP_LOG=1;

set gemnetid 'gemnetobject -C GEM_ENV=GEMSTONE_KEEP_LOG=1'

RTLD_DEEPBIND no longer used; User Action relink required

The RTLD_DEEPBIND option for dlopen() is no longer used by GemStone when loading shared libraries. The RTLD_DEEPBIND option caused unintended side effects when used with the LD_PRELOAD environment variable. See the Linux man pages for dlopen and for ld.so, for further information.

This change affects GemStone running on Linux only. On Linux, all user actions that were compiled/linked with v3.5 must be recompiled/relinked for 3.5.1.

When linking a GCI application, you should now explicitly specify the -Bdynamic flag; previously this could be omitted. The following is updated:

g++ userCode.o $GEMSTONE/lib/gcirtlobj.o -Wl,-traditional 

-Wl,-z,lazy -m64 -Wl,-Bdynamic,--no-as-needed -lpthread 

-Wl,--as-needed -lcrypt -ldl -lc -lm -lrt -o userAppl

Change in linker flags for Solaris

When building user actions on Solaris, the -Bsymbolic linker flag should no longer be needed or used. The following is updated:

CC -m64 -xarch=generic -G -h libuserAct.so -i userCode.o

$GEMSTONE/lib/gciualib.o -o libuserAct.so -Bdynamic -lc 

-lsendfile -lpthread -ldl -lrt -lsocket -lnsl -lm -lpam 

-lCrun -z nodefs

Other Added GCI functions

The following other GCI functions have been added:

GciLogout_
Similar to GciLogout, but accepts a Boolean argument. A true argument is the same as GciLogout, waits for a reply packet from the gem. If the argument is FALSE, the library sends the logout command and closes the connection without waiting for a reply from the gem.

(void) 	GciLogout_( 

	   BoolType getResult

	   );

GciShutdown_
Similar to GciShutdown, but accepts a Boolean argument.

(void) 	GciShutdown_( 

	   BoolType doLogouts

	   );

Changes in Thread-safe GCI

There have been a number of changes in thread-safe GCI calls that may affect existing applications. All thread-safe GCI applications will require attention, minimally to update the GciTsLogin/GciTsForkLogin calls.

BoolType *executedSessionInit

ushort environmentId;

GciTravBufType *travBuff,

int flag,

(BoolType) GciTsDirtyObjsInit(

    GciSession sess,

    GciErrSType *err );

(OopType) GciTsI32ToOop(

    int arg );

(BoolType) GciTsX509ForkedLogin(

    GciX509LoginArg *args,

    BoolType *executedSessionInit,

    GciErrSType *err,

    GciTsCallbackFType *callback );

(GciSession) GciTsX509Login(

    GciX509LoginArg *args,

    BoolType *executedSessionInit,

    GciErrSType *err );

Changes in Cache Statistics

The following statistics have been removed:

LogHighQueueAdds
LogHighQueueSize
LogLowQueueAdds
LogLowQueueSize

The following statistics have been added:

LogAioQueueAdds (Stone)
The total number of times a session was added to the tranlog aio write queue.

LogAioQueueSize (Stone)
The current number of sessions in the tranlog aio write queue.

LogBufQueueAdds (Stone)
The total number of times a session was added to the tranlog buffer queue.

LogBufQueueSize (Stone)
The current number of sessions in the tranlog buffer queue.

GciStoreTravDoTravRefs issues with serious GBS impact

Terminated GsProcess may not have allowed ensure block to complete

When sending terminate to a GsProcess that is executing an ensure block, there is a risk that the timeout may expire before the ensure block completes.

The timeout in GsProcess>>terminate has been raised from 10 to 30 seconds to reduce the risk of this problem. (#48271)

STN_COMMITS_ASYNC risk of lost record

With STN_COMMITS_ASYNC set to true, if the tranlogs become full and the Stone had to wait for more space to become available, the tranlog record that was waiting to be written may not actually have been written, depending on the particular point in which the tranlog directories full conditions are encountered. This caused an error on restore. (#48098)

STN_COMMITS_ASYNC was disabled in v3.5 and 3.4.4.

GciNewUtf8String does not put result object in export set

The GCI function GciNewUtf8String() does not put the newly created object in the export set, which may allow it to be garbage collected while still in use. (#48217)

startstone with precheckpoint and checkpoint records in different tranlogs

It is possible for the precheckpoint and checkpoint records to be written to two different tranlogs. In this case, startstone may fail in spite of a clean shutdown. (#48169)

libgcirpc shared library load performance

Due to changes in the way openSSL libraries were located, there were cases, such as when loading libraries over NFS on heavily loaded system, in which the time required to load the libraries was much slower. (#48171)

Reclaim issues

NetLDI failed to close socket if Gem process fork fails

During an RPC login, the NetLDI forks the Gem Process, creating sockets to manage further communications. The NetLDI was failing to close these sockets if the fork failed for some reason, such as unable to create the gem log file. These open sockets could eventually cause NetLDI to fail due to too many open files in the NetLDI process. (#48370)

SEGV or Access Violation in user action

If the OOP of the name of a user action is larger than 549755813633, and this OOP has bit 0x8000000000 set, errors in the code produce a negative hash value, which causes a SEGV on Unix and an Access violation error on Windows. (#48126)

Incorrect compiler optimization

There was an error in the compiler’s optimization of certain expressions, for example (object ifNil:[ nil ]) == object, such that this could return incorrect results. (#48224)

RC objects not handled correctly in nested transactions

Reduced Conflict (RC) objects (such as RcKeyValueDictionary, etc.) maintain changes in a redo log that allows a commit conflict to be resolved by replay. However, when an RC object was modified within a nested transaction, and that nested transaction was aborted, the redo log was not updated. If later, the RC object has further changes, and the commit again has conflicts such that the redo log is replayed, the changes that had been made earlier and aborted may be applied. (#48389)

continuousRestoreFromArchiveLogs could fail on initial setup

When setting up a new a hot standby system, the final steps are to run startlogreceiver, and then to execute continuousRestoreFromArchiveLogs: on the slave system. However, it takes a few seconds after executing startlogreceiver before the tranlogs are available on the slave system. If continuousRestoreFromArchiveLogs: is executed immediately after the startlogreceiver is started up, before any logs were available, it failed with a file not found error. (#48346)

Issues related to Configuration Parameters

Restore Issues

startCheckpointSync did not always checkpoint the current state

Previously, if startCheckpointSync was started while a checkpoint was going on, it would return at the end of that checkpoint. This left a potential gap between the start of that checkpoint (which could be some time ago), and the moment at which startCheckpointSync was invoked. Now, if a checkpoint is underway when this method is invoked, a second checkpoint is started immediately after that one completes. This ensures that all changes, as of the time that startCheckpointSync is invoked, are written to the extents. (#48360)

backup start time was not reported in stone log

The stone log normally contains the time a full programmatic backup was started and the time it completed. The start message was not being included. (#48100)

Issues related to remote caches

GCI client on Windows 7 hang on socket disconnect

A GCI client (including RPC GBS and topaz) on Windows 7 may hang when a socket is killed and the Gem exits. This is related to that OS version’s socket library returning EWOULDBLOCK, which otherwise implies data on the socket. The GCI client code now recognizes this condition and will terminate the connection. (#48448)

Find reference path search missed references via class instance variables

If the only reference to an object was via a class instance variable, and the class itself was not in any user’s SymbolDictionaries, the object could be incorrectly reported as unreachable/dead. (#48447)

GsBitmap issues

Issues specific to X509-Secured GemStone

Further testing has been done on X509-Secured GemStone and a number of issues have been fixed.

DecimalFloat >> asStringUsingFormat: did not 0-pad per argument

The arguments to asStringUsingFormat: include the number of digits to include following the decimal point. While DecimalFloat rounded if there were more digits, it did not pad with 0 as documented to the minimum number of digits. (#48305)

System >> hostCpuUsage results

It was possible for System >> hostCpuUsage to return an array of zeros. (#48220).

Note that invalid results, indicating 100% idle, are still returned in some cases (such as on Linux for the first call and for two calls too close together).

The code supporting this method also did not round predictably, so the percentages of CPU did not always add up to 100. (#48232)

GsFile issues

copydbf -Z broken

The -Z option to the copydbf utilities reported an invalid compression argument error. (#48188)

Missing collection protocol for CanonStringDict and CanonSymbolDict

These specialized collections did not implement the collection methods do:, select:, reject:, and collect:. (#48286)

Incorrect report of fatal error in configuration files

There were code paths in Gem startup in which an unrelated error could incorrectly trigger the warning message "!!! FATAL ERRORS IN GemStone CONFIGURATION FILES !!!". (#48395)

Diagnosing GsExternalSession login errors

When using GsExternalSession to login, and login failed, determining the cause by examining the specific login parameters was difficult. Now, a login error will also report details of the GsExternalSession parameters. (#48083)

gemnetobject_slow failed to load slow; ran fast libraries

GemStone provides "slow" libraries, which have less optimization and additional assertion checks, for debugging. Due to distribution changes in v3.5, using gemnetobject_slow could fail in loading the slow shared library, in which case it fell back to using the regular fast library. (#48219). See here for the additional distribution changes in v3.5.1.

become: crashed with extremely large NSC

Sending become: to a million-item UnorderedCollection (Non-sequential collection), such as IdentityBag, could crash the Gem with a SEGV. (#48294)

Extra step point at beginning of method

The compiler produced an extra step point at the beginning of methods, although there was not actually a step point there. (#48118)

Programmatic GemNativeCodeEnabled value for true

The configuration parameter GemNativeCodeEnabled can accept 0, 1, or 2. For backwards compatibility, it can also be set to false (0) or true (2). However, access by means of System configurationAt: #GemNativeCodeEnabled [ put: ] translated true to 1; in v3.5.1, true translates to 2. (#47661)

GsCurrentSession >> inTransaction returned integer rather than boolean

This method was documented to return a boolean; however, it returned 1 or 0. (#48290)

References to obsolete class JISCharacter in source code

The source code for an image method contained a reference to the class JISCharacter, which was moved to ObsoleteClasses in 3.5. This method could not be recompiled. The reference has been removed. (#48343)

RcKeyValueDictionary hard coded references to RcCollisionBucket

It is allowed to create customized collision buckets for a subclass of RcKeyValueDictionary; however, there were hardcoded references directly to RcCollisionBucket. These have been changed to invoke _bucketClass. (#48390)