1. GemStone/S 64 Bit 2.4.7 Release Notes 
Overview
GemStone/S 64 Bit 2.4.7 is a new version of the GemStone/S 64 Bit object server. This release fixes a number of bugs, and adds some new features.
The GemStone/S 64 Bit 2.4.x version line is under legacy support; we recommend customers upgrade to the latest version, currently 3.2.11, to take advantage of the performance benefits, new features, and bug fixes. Version 2.4.7, provides a subset of key improvements, for customers who are not yet able to upgrade to v3.x.
These release notes provide changes between the previous version of GemStone/S 64 Bit, version 2.4.6, and version 2.4.7. If you are upgrading from a version prior to 2.4.6, review the release notes for each intermediate release to see the full set of changes.
For details about installing GemStone/S 64 Bit 2.4.7 or upgrading from earlier versions of GemStone/S 64 Bit, see the GemStone/S 64 Bit Installation Guide for v2.4.7 for your platform.
Supported Platforms
Platforms for Version 2.4.7
GemStone/S 64 Bit version 2.4.7 is supported on the following platforms:
- Solaris 10 and 11 on SPARC
- Solaris 10 on x86
- AIX 6.1 and AIX 7.1
- Red Hat Linux ES 6.4, 6.5, and 6.7; Ubuntu 12.04; and SUSE Linux Enterprise 12, on x86
For more information and detailed requirements for supported platforms, please refer to the GemStone/S 64 Bit Installation Guide for that platform.
GBS Versions
The following versions of GBS are supported with GemStone/S 64 Bit version 2.4.7.
GBS version 7.6.1
VSD Version
Since v2.4.6, there have been many changes in how VSD is managed. VSD is now distributed as a separate product with separate version numbers and separate documentation, as well as included with the GemStone/64 Bit distributions.
VSD has updated TCL and other libraries, and has been completely rebuilt for Windows. The VSD distributions is now included with the GemStone/S 64 Bit client library distribution on Windows.
The GemStone/S 64 Bit v2.4.7 distribution includes VSD version 5.0.1.
For Documentation, and Release Notes that include recent changes, see https://gemtalksystems.com/products/vsd.
Changes and New Features
Updated Client Platforms
Version 2.4.7 has updated platforms from the previous version; in some cases the base platform version has changed.
In particular, the Windows Client libraries have been recompiled on later versions, since Windows XP has passed its end-of-life. Client applications on Windows must now use Windows 2008/Windows 7 or later.
The Installation Guides have been updated with new platform information. For updated compile and link flags, see GCI Compile and Link Information.
Distribution changes related to VSD
GemStone distributions on all platforms include 64-bit VSD, with additional file/s that are part of recent VSD versions. In addition, the distribution includes a directory $GEMSTONE/bin32, which contains 32-bit VSD.
Increase in hard limit to number of sessions
Previously, the hard upper limit on the STN_MAX_SESSIONS was 10000; this limit has been increased to 32767.
Support for pageaudit -d option
The pagaudit utility now supports the -d option, which skips auditing data pages. Default auditing of data pages by pageaudit was added in v2.4.5.
Linux Posix AIO feature removed
Previous versions included an optimization to allow use of Posix AIO on Linux. The third-party libraries supporting this feature have not been maintained, and the performance benefit is not needed with newer Linux configurations, so this feature and associated executables have been removed.
Admin gem now shut down during restore from backup
To avoid potential conflicts between GC operations during restore, the Admin GcGem is now shut down during restore from backup.
Support for 2M Memory Pages for SPC on Linux
By default, Linux uses 4KB (small) pages. With v2.4.7, you may now configure your system to use 2MB Large Memory Pages on Linux for the shared page cache.
To use large memory pages on Linux for the shared page cache, you must first determine how much space you require for the SPC and configure Linux to allocate at least this many large memory pages, and then enable GemStone/S 64 Bit to request large memory pages by setting an environment variable prior to startup.
Determining the required number of large memory pages
You will first need to determine how much space is needed for the shared page cache. This is a two-step process.
(1) The easiest way to get the required values is to start up GemStone with the desired configuration, and inspect the shared page cache monitor log. These example numbers are for a system with a 20 GB cache. Looking at the stonename_pidpcmon.log, these are the values that are needed:
Number of pages 1250000
Number of processes 1022
TargetFreeFrameCount 7000
Number of shared counters 1900
(2) Once you have the GemStone parameters, start the shrpcmonitor directly and enter the parameters to compute the target size.
unix>$GEMSTONE/sys/shrpcmonitor
<prints header information>
SHRPCMON>1250000 setnumpages
SHRPCMON>1022 setnumprocs
SHRPCMON>1900 setnumsharedctrs
SHRPCMON>7000 settargetfflimit
SHRPCMON>getrequiredsizeFor 1250000 pages, 1022 processes and 1900 shared counters,
required cache size is 21325807616 bytes.
To use 2 MB large memory pages: 21325938688 bytes are required for alignment.
Number of 2 MB large pages required: 10169
Commands to enable large pages on Linux. Run as root:
#echo 10169 > /proc/sys/vm/nr_hugepages
The above command only enables large pages until the next system reboot.
To permanently enable large pages, you must also do this as root:
#echo "vm.nr_hugepages=10169" >> /etc/sysctl.conf
Commands to enable the shared page cache monitor to allocate large memory pages:
#/sbin/setcap cap_ipc_lock=pe $GEMSTONE/sys/startshrpcmon
#/sbin/setcap cap_ipc_lock=pe $GEMSTONE/sys/shrpcmonitor
Alternatively, the SPC monitor process can be run with an
effective user ID of root:
#chown root $GEMSTONE/sys/shrpcmonitor
$GEMSTONE/sys/startshrpcmon
#chmod u+s $GEMSTONE/sys/shrpcmonitor
$GEMSTONE/sys/startshrpcmon
Command to query the status of large pages:
>grep Huge /proc/meminfo
In this example, the result of the computation is that the shared page cache will require 21325807616 bytes (the 20 MB configured size plus overhead).
Large memory pages are 2 MB, so divide 21325807616 by the 2MB page size, rounding up for alignment. This gives a minimum of 10169 large memory pages that are required for a SPC with this configuration.
These computations are included in the output from getrequiredsize.
Configure Linux to use the required number of Large Memory Pages
Linux must be configured to use the required number of large pages, by executing the following commands. These instructions are also output by getrequiredsize.
You must execute these as root.
To enable large pages in the current system, which will be in effect until the next system reboot:
echo numpages > /proc/sys/vm/nr_hugepages
To permanently enable large pages:
echo "vm.nr_hugepages=numpages" >> /etc/sysctl.conf
You can confirm large memory pages are available for use with:
grep Huge /proc/meminfo
Enable the Process to Allocate Large Pages
You can configure the executables to be allowed to allocate large pages:
/sbin/setcap cap_ipc_lock=pe $GEMSTONE/sys/startshrpcmon
/sbin/setcap cap_ipc_lock=pe $GEMSTONE/sys/shrpcmonitor
Alternatively, the SPC monitor process can be run with an effective user ID of root:
chown root $GEMSTONE/sys/shrpcmonitor $GEMSTONE/sys/startshrpcmon
chmod u+s $GEMSTONE/sys/shrpcmonitor $GEMSTONE/sys/startshrpcmon
Enabling Large Memory Pages in GemStone/64
GemStone will attempt to allocate the shared page cache using large memory pages based on the value of the added environment variable GS_SPC_USE_LARGE_PAGES.
- If this is not set, large pages are not used.
- if this is set to 1, it is advisory mode: Large memory pages are requested but the cache still starts if the request is not granted by the system.
- If this is set to 2, it is mandatory mode. Large memory pages are requested and the cache fails to start if the request is not granted by the system.
When you start GemStone, the shared page cache monitor log will include a line of the form:
[Info]: Shared page cache was successfully created using large memory pages.
Changes in Cache Statistics
Change in GemStone process statistics on Linux
On Linux, cache statistics are collected from /proc/pid/status rather than from /proc/pid/statm. This provides some additional statistics, included in the lists below.
As a result of this change, SharedKBytes and RSSDirty are no longer collected on Linux
Added statistics for Linux only
MaxImageSize (All)
The maximum (high water) size of the process's image in kilobytes.
MaxRSS (All)
The high water mark of the processes resident set size.
RSSStack (All)
The stack resident set size.
PageTablesMemoryKB (All)
The amount of memory dedicated to low-level page tables.
ThreadCount (All)
Number of threads currently active in this process. An instruction is the basic unit of execution in a processor, and a thread is the object that executes instructions. Every running process has at least one thread.
VolCSW (All)
The number of voluntary context switches done by the process. Note that this counter is always 0 on HP-UX.
IVolCSW (All)
The number of times the process was forced to do a context switch. Note that this counter is always 0 on HP-UX.
FileBufferSizeKB (System statistic)
The amount of memory used in file buffers.
CachedMemoryKB (System statistic)
The amount of memory used as cache memory.
CachedSwapKB (System statistic)
The amount of swap used as cache memory.
ActiveMemoryKB (System statistic)
The amount of memory that has been used more recently and usually not reclaimed unless absolutely necessary.
InactiveMemoryKB (System statistic)
The amount of memory which has been less recently used. It is more eligible to be reclaimed for other purposes.
ActiveAnonMemoryKB (System statistic)
The amount of non-file backed memory that has been used more recently.
InactiveAnonMemoryKB (System statistic)
The amount of non-file backed memory that has not been used recently.
ActiveFileMemoryKB (System statistic)
The amount of memory used for buffering files that has been used recently.
InactiveFileMemoryKB (System statistic)
The amount of memory used for buffering files that has not been used recently.
UnevictableMemoryKB (System statistic)
The amount of memory that cannot be swapped.
LockedMemoryKB (System statistic)
The amount of memory that has been locked using mlock(2) or similar calls. Locked memory cannot be swapped.
WritebackMemoryKB (System statistic)
The amount of memory which is actively being written back to disk.
AnonymousMemoryKB (System statistic)
The amount of non-file backed memory mapped into userspace page tables.
MappedMemoryKB (System statistic)
The amount of memory which has been mapped to files.
SharedMemoryKB (System statistic)
The amount of memory enabled for sharing between multiple processes via shmat(2) and mmap(2) with the MAP_SHARED attribute set.
KernelDataMemoryKB (System statistic)
The amount of memory used by the kernel for caching data structures.
KernelDataReclaimableMemoryKB (System statistic)
The amount of memory used by the kernel for caching data structures that may be reclaimed.
KernelDataUnreclaimableMemoryKB (System statistic)
The amount of memory used by the kernel for caching data structures that cannot be reclaimed.
KernelStackMemoryKB (System statistic)
The amount of memory used by the kernel stack.
PageTablesMemoryKB (System statistic)
The amount of memory dedicated to low-level page tables.
NfsUnstableMemoryKB (System statistic)
The amount of memory used by NFS pages sent to the server, but not yet committed to stable storage.
BounceMemoryKB (System statistic)
The amount of memory used for bounce buffers for block devices.
WritebackTmpMemoryKB (System statistic)
Amount of memory used by FUSE (Filesystem in Userspace) filesystems.
CommitLimitKB (System statistic)
The total amount of memory currently available to be allocated on the system.
CommittedAsKB (System statistic)
The amount of memory presently allocated on the system, including memory allocated by processes that has not yet been used.
HardwareCorrupted (System statistic)
A boolean indicating if the system has detected a memory failure.
AnonHugePagesKB (System statistic)
The amount of non-file back memory backed by huge memory pages.
HugePagesTotalKB (System statistic)
The total amount of memory in the huge pages pool.
HugePagesFreeKB (System statistic)
The amount of memory in the huge pages pool that has not yet been allocated.
HugePagesRsvdKB (System statistic)
The amount of memory in the huge pages pool for which a commitment to allocate from the pool has been made, but no allocation has yet been made.
HugePagesSurpKB (System statistic)
The amount of memory in the huge pages pool above the value in /proc/sys/vm/nr_hugepages.
HugePageSize (System statistic)
The size of a huge memory page in bytes.
GCI Compile and Link Information
AIX
Compiling a User Action or GCI Application
xlC_r -O3 -qstrict -qalias=noansi -+ -D_REENTRANT -DNOT_JAVA_VM
-D_THREAD_SAFE -q64 -qpic -qnoeh -qthreaded -qarch=pwr5
-qtune=balanced -qlist=offset -DFLG_AIX_VERSION=aixVer
-qsuppress=1500-010:1500-029:1540-1103:1540-2907:1540-0804:1540-1281:1540-1090
-qminimaltoc -I$GEMSTONE/include -c userCode.c -o userCode.o
Depending on your version of AIX, you need to include either -DFLG_AIX_VERSION=61 or -DFLG_AIX_VERSION=71.
Also note that there is no space in the -qsuppress arguments that are continued on the following line.
Linux
Compiling a User Action or GCI Application
g++ -fmessage-length=0 -fcheck-new -O3 -m64 -pipe -D_REENTRANT
-DNOT_JAVA_VM -D_GNU_SOURCE -pthread -fPIC -m64
-fno-strict-aliasing -I$GEMSTONE/include -x c++ -c userCode.c
-o userCode.o
The following warn flags are recommended for compilation:
-Wformat -Wtrigraphs -Wcomment -Wsystem-headers -Wswitch
-Wno-aggregate-return -Wshadow -Wunused-value -Wunused-variable
-Wunused-label -Wno-unused-function -Wchar-subscripts
-Wconversion -Wmissing-braces -Wmultichar -Wparentheses
-Wsign-compare -Wsign-promo -Wwrite-strings -Wreturn-type
Solaris/SPARC
Compiling a User Action or GCI Application
CC -xO4 -xcode=pic32 -xarch=v9 -mt -xchip=ultra2 -D_REENTRANT
-DNOT_JAVA_VM -I$GEMSTONE/include -features=no%except
-features=no%anachronisms -c userCode.c -o userCode.o
Solaris x86
Compiling a User Action or GCI Application
CC -xO4 -m64 -Kpic -mt -D_REENTRANT -DNOT_JAVA_VM
-I$GEMSTONE/include -features=no%except -c userCode.c
-o userCode.o
Bug Fixes
The following bugs are fixed in the 2.4.7 release:
NetGetPeer info may SEGV
Lookup failure in gethostbyaddr_r, when looking up the name for the IP address of the gem socket connection, may SEGV. (#44804)
Stone startup failure timeout too long
If the shared page cache cannot be started, the SPC monitor fails immediately, but the startup failure was not reported to the user until a timeout had elapsed. (#45763)
Conversion Related Issues
Indexing Related Issues
Faster removal of all indexes
When dropping all indexes in the repository, you may now do this more efficiently using the new method IndexManager >> removeAllTracking. This method not only removes indexes, but also removes all modification tracking (clears all DependencyLists and reinitializes SharedDependencyList). This is faster and more efficient than removeAllIndexes. However, if you are using modification tracking for another purpose, such as with GemConnect, this method should not be used, since that tracking would also be removed.
DependencyList not in SharedDependencyList
It was possible for DependencyLists to not be in the SharedDepedencyLists structure, and this was not caught by index audit. There was no error conditions resulting from this; the consequence was extra instances of DependencyList. This condition is now caught by audit, and repaired. (#41868)
IndexManager did not autoCommit during DependencyList removal
When removing an index, the IndexManager autoCommit normally allows periodic commits. This was not occurring during execution while removing DependencyLists. With a very large number of DependencyLists, this could result in excessively large dirty sets. (#43647)
removeAllIncompleteIndexes may error, preventing index removal
When an incompletely created index had been left with particular internal indexing structure variables that were nil or of size zero, removeAllIncompleteIndexes resulted in an error. #(43658)
Corrupted RcIndexBucketWithCache has nil for cacheValue instead of number
GemStone identity indexes and most equality indexes use an internal structure, an instance of RcIndexDictionary, which contains instances of RcIndexBucketWithCache. When these collision buckets are fully packed (1380 entries), removing an element may corrupt the RcIndexBucketWithCache, and thus the index. (#43801)
Bugs in Cache Statistics
Linux network stats had incorrect values
The statistics related to network performance were incorrect for Linux hosts; some values were unreasonably high, others were zero. (#45051)
Linux cache statistics PercentCpu* stats may go out of range
System cache statistics such as PercentCpuActive, PercentCpuIdle, etc., could be reported as greater than 100 or less than 0. (#45729)
AIX cache statistic PercentCpuIdle may have invalid value
The calculation for the cache statistics PercentCpuIdle was subject to a rounding error, which resulted in values of -1 recorded in statmonitor data. VSD displayed this as an unsigned int, 4294967295. (#45654)