JDK-6464834 : ObjectOutputStream's internal array management limits maximum size
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io:serialization
  • Affected Version: 6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2006-08-29
  • Updated: 2013-05-01
Related Reports
Relates :  
JDK-5089202 - cannot allocate a java.lang.StringBuffer object with size of 1GB
Relates :  
JDK-6991552 - RFE: Internal arrays of ObjectInputStream/ObjectOutputStream not to grow exponentially
Relates :  
JDK-6460346 - Can't serialize an object graph with more than 184,549,375 elements.
Description
Extracting the library related issue from 6460346. In ObjectOutputStream the HandleTable class grows its internal arrays by always doubling the length and adding one. This will overflow well short of the physical maximum length of Integer.MAX_VALUE. On 64-bit systems such 32-bit limits may be reachable, once the VM limitations have been removed.
Comments
SUGGESTED FIX With the fix for 5089202, it's not obvious that simply changing the array growth formula to doubling powers of two would actually improve the situation-- it would seem better to detect overflow explicitly. Also, note that the one of the arrays in ObjectOutputStream.HandleTable, "spine", is indexed by identity hash codes (mod the array length), so power-of-two length bucket arrays would seem problematic without a supplemental hash function (see java.util.HashMap.hash-- I don't think that we can assume that System.identityHashCode provides good enough distribution on its own).
07-09-2006
SUGGESTED FIX The simple solution for this bug is to set the initial capacity for the OOS.HandleTable and OIS.HandleTable as a power of two(8 or 16), as it was implemented for example in the HashMap class. This solution covers the customer issue and might be considered as the low risk improvement.
29-08-2006
EVALUATION will look into this in next release
29-08-2006