Bug 48311

Bug: 48311

Impact:

Informational

Product:

GemStone/S 64 Bit

Versions:

3.7.1, 3.7, 3.6.8, 3.6.7, 3.6.6, 3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.2, 3.3.1, 3.3, 3.2.16, 3.2.15, 3.2.14, 3.2.x, 3.x, 2.4.8, 2.4.4.8, 2.4.4.7, 2.2.6.5, 2.x

Platform:

Fixed In:

Collection fanout in repositories that did not run postconv after conversion from 32-bit

Large collections in GemStone are represented internally in a tree structure, with nodes designed to fit on a GemStone page.  Since the page size in GemStone/S 64 Bit  is larger than the page size in 32-bit GemStone/S, the conversion process included a step, postconv, that converted the 32-bit collection fanout to the new 64-bit fanout.

If the postconv conversion step is skipped, the old fanout will continue to be used and is fully supported.  However, there may be some performance penalty as more leaf node pages may need to be read to access elements of the collection.

Object audit will report a warning if it detects collections (other than NSCs) that are in the old fanout form.

Object Audit: Audit successfully completed; no errors were detected.
[WARNING] nnnn objects found with the oldLrgFanout
  These objects are saved in hiddenSet Reserved1 (26)
  and could be optimized by converting to 64bit fanout

(the message may vary in later versions of GemStone/S 64 Bit)

If you do not have a problem with collection performance, the warning can be disregarded.

Workaround

The collections can be rebuilt, by creating a new collection, adding each content object to the new collection, and doing a become:.  The specific details will depend on the collection class.

Note that due to the different ways NSCs (such as IdentityBag) are constructed, it is not simple to distinguish an NSC with an old fanout from one that happens to be sparse.