RFR 4358774: Add null InputStream and OutputStream (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Thu Dec 7 03:03:30 UTC 2017

On Wed, Dec 6, 2017 at 4:01 PM, Jason Mehrens <jason_mehrens at hotmail.com> wrote:

Brian,

My understand is JDK-6533165 is moving the bytes that are rarely invoked to a cold method. Therefore: ==== if (closed) { throw new IOException("Stream closed"); } ==becomes=== if (closed) { throw sc(); } private static IOException sc() { return new IOException("Stream closed"); } ================================ Since there is no string concatenation in the IOE message there are only a few bytes that can be shaved off. I didn't benchmark it either case but I would assume it would matter for the nullOutputStream since the write methods could be invoked multiple times. From a performance angle, I'd be more concerned with the calls to Objects.xyz() methods there. Unless something has changed in the JIT recently, those are susceptible to profile pollution and can cause missed optimizations. I'd inline those methods manually to give these methods their own profiles.

Jason

From: Brian Burkhalter <brian.burkhalter at oracle.com> Sent: Wednesday, December 6, 2017 2:05 PM To: Jason Mehrens Cc: core-libs-dev Subject: Re: RFR 4358774: Add null InputStream and OutputStream

Jason, On Dec 6, 2017, at 11:54 AM, Jason Mehrens <jasonmehrens at hotmail.com<_ _mailto:jasonmehrens at hotmail.com>> wrote: For nullInputStream would it make any sense to use the ByteArrayInputStream with a (private static) empty byte array? Maybe 'return new ByteArrayInputStream("".getBytes());'? One side effect is that mark support returns true. As we are trying to retain the behavior of closed streams throwing IOExceptions I don’t think that BAIS would work here. Does it make sense to follow the advice inhttps://bugs.openjdk.java. net/browse/JDK-6533165 with regards to streams being closed? I don’t know exactly what you intend here. In the linked issue there is information to impart, namely the index and the size. Here there is only the indication that the stream is closed. It’s not clear to me what could be done here. Thanks, Brian

More information about the core-libs-dev mailing list