RFR: 8222532: (zipfs) Performance regression when writing ZipFileSystem entries in parallel

[Langer, Christoph]

Hi Claes,

I checked the change and it looks fine to me, too. It contains some nice cleanups.

I have a few nits, no need for a new webrev though:
ZipFileSystem.java:
- The added imports java.nio.channels.Channels and java.nio.channels.NonWritableChannelException don't seem to be necessary to me.
- EntryOutputChannel::close (line 627 ff): Maybe you want to use try-with-resources for the output stream from getOutputStream(e) ?
- line 634, private int getCompressMethod(FileAttribute<?>... attrs) {... As you're about to clean it up, I guess you should remove the unused attrs from the method signature, too.
- line 2510: 2510     private static class ExChannelCloser  { -> there is a space too much between "ExChannelCloser"  and "{"

Best regards
Christoph

> -----Original Message-----
> From: nio-dev <nio-dev-bounces at openjdk.java.net> On Behalf Of Claes
> Redestad
> Sent: Montag, 22. April 2019 22:16
> To: Lance Andersen <lance.andersen at oracle.com>
> Cc: nio-dev at openjdk.java.net
> Subject: Re: RFR: 8222532: (zipfs) Performance regression when writing
> ZipFileSystem entries in parallel
> 
> Hi Lance,
> 
> On 2019-04-22 21:26, Lance Andersen wrote:
> > Hi Claes,
> >
> > Thank you for your efforts here.
> >
> > I have gone through your changes, comparing to the original code prior
> > to JDK-8034802 and your changes look good.  It would be good if someone
> > else can  also help sanity check but you did a nice job of adding the
> > functionality back.
> 
> thanks for reviewing! And yes, I'd appreciate more reviews, too. :-)
> 
> >
> > Before you push, please update the copyright for ZipFileSystemProvider.
> 
> Sure
> 
> Thanks!
> 
> /Claes
> >
> > Best,
> > Lance
> >> On Apr 18, 2019, at 9:10 AM, Claes Redestad <claes.redestad at oracle.com
> >> <mailto:claes.redestad at oracle.com>> wrote:
> >>
> >> Hi,
> >>
> >> JDK-8034802 changed zipfs to defer deflation to only happen when
> >> closing/syncing the ZipFileSystem. Previously it happened eagerly when
> >> closing output streams retrieved via Files.newOutputStream. While this
> >> behavior change could have positive effects in some cases (since
> >> reading/writing entries don't need to inflate/deflate on the fly), it
> >> also broke the ability to deflate entries in parallel.
> >>
> >> This patch reverts the behavior so that entries are deflated (by
> >> default) when individual entry output streams are closed. File channels
> >> retain the behavior that entries are inflated into an internal byte
> >> array.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222532
> >> Webrev: http://cr.openjdk.java.net/~redestad/8222532/open.00/
> >>
> >> Testing: tier1-3, verified recuperation of performance in reproducer to
> >> pre-JDK-8034802 levels.
> >>
> >> Thanks!
> >>
> >> /Claes
> >
> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> > <http://oracle.com/us/design/oracle-email-sig-
> 198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> > <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance
> Andersen|
> > Principal Member of Technical Staff | +1.781.442.2037
> > Oracle Java Engineering
> > 1 Network Drive
> > Burlington, MA 01803
> > Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> >
> >
> >