JDK-8352891 Performance improvements to ByteArrayOutputStream
    Engebretson, John 
    jengebr at amazon.com
       
    Mon Apr 14 12:59:04 UTC 2025
    
    
  
I thought about this over the weekend, and I think the byte[] variant and the Object[] variant target separate problems: byte[] targets I/O patterns and Object[]
targets Collections.
So my current mental model is:
public class java.io.VariableLengthByteArray {
  // whatever views we want to support
  public ByteArrayOutputStream asOutputStream();
  public InputStream asInputStream();
  public SeekableByteChannel asByteChannel;
  // provides long-indexed methods
  public byte get(long index);
  public long get(long index, byte[] buf);
  public byte set(long index, byte b); // return old value
  public long size(); // note the long
  // optional: inserts/removes by long index
  // add to tail
  public void add(byte b);
  public void add(byte[] b, int off, int len);
  public void add(VariableLengthByteArray other);
  public void add(ByteBuffer buf);
  // size-limited methods
  public int sizeAsInt(); // requires int range
  public byte[] toArray(); // requires int range
  public String toString(); // requires int range
  // miscellaneous
  public void clear();
}
public class java.util.HugeCollections {
  // views are capable and efficient with size > Integer.MAX_VALUE
  public static <T> List<T> getList(); // this structure
  public static <T> Set<T> getSet(); // segmented hash table
  public static <T> Map<T> getMap(); // segmented hash table
  // how do we retrieve the long size?
}
Unfortunately, I don't see a way to avoid two public types while retaining the capabilities.
Archie, thank you for all of the questions/suggestions last week, they really sparked some ideas.
  John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250414/40dec65f/attachment.htm>
    
    
More information about the core-libs-dev
mailing list