On Thu, Dec 7, 2017 at 9:40 AM Roger Riggs <roger.ri...@oracle.com> wrote:
> Hmm...
>
> Seems like a lot of fine tuning for a function that has a low profile and
> no
> performance data...
These are known issues in the current JIT optimizer. We all wish we didn’t
have to do this stuff. If we want the best chance of these noop impls to
actually be close to noop then it warrants consideration. If that’s not a
concern then sure, nothing to discuss. That’s all :).
I also wouldn’t say “it’s a lot of fine tuning” - these are simple
mechanical things.
>
>
> $.02, Roger
>
> On 12/6/2017 10:03 PM, Vitaly Davidovich wrote:
> > On Wed, Dec 6, 2017 at 4:01 PM, Jason Mehrens <jason_mehr...@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.burkhal...@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 <jason_mehr...@hotmail.com<
> >> mailto:jason_mehr...@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
> >>
>
> --
Sent from my phone
