On 23/04/2019 08:19, Lennart Börjeson wrote:
Any chance we might get this repaired in time for the Java 13 ramp down?
Under discussion/review here:
https://mail.openjdk.java.net/pipermail/nio-dev/2019-April/006043.html
ehalf
>> Of Xueming Shen
>> Sent: Dienstag, 16. April 2019 22:50
>> To: Lennart Börjeson
>> Cc: core-libs-dev@openjdk.java.net
>> Subject: Re: ZipFileSystem performance regression
>>
>> Well, have to admitted I didn't expect your use scenario when made the
&g
Anthony
From: core-libs-dev on behalf of Peter
Levart
Sent: Wednesday, April 17, 2019 9:23:08 AM
To: Claes Redestad; Lance Andersen; Xueming Shen
Cc: core-libs-dev@openjdk.java.net
Subject: Re: ZipFileSystem performance regression
Just a thought...
Would
Just a thought...
Would it be feasible to create a brand new "Generic Caching Filesystem"
implementation that would delegate to another filesystem for persistent
storage (be it ZipFilesystem or any other) and implement interesting
caching strategies (lazy flushing, concurrent flushing,
It sounds reasonable to have that as an option, but I'd like to see it
requested by some user first. And at least one (micro-)benchmark where
keeping entries uncompressed in memory actually shows significant
positive impact.
I can see it might have the opposite effect depending on how often that
Would it be worth adding a ZIP File System property similar to createNew which
enables/disables the change that Claes has made having the default be the
pre-jdk 12 functionality?
> On Apr 16, 2019, at 4:50 PM, Xueming Shen wrote:
>
> Well, have to admitted I didn't expect your use scenario
-Original Message-
> From: core-libs-dev On Behalf
> Of Xueming Shen
> Sent: Dienstag, 16. April 2019 22:50
> To: Lennart Börjeson
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: ZipFileSystem performance regression
>
> Well, have to admitted I didn't expect you
Well, have to admitted I didn't expect your use scenario when made the
change. Thought as a
filesystem runtime access performance has more weight compared to
shutdown performance...
basically you are no using zipfs as a filesystem, but another jar tool
that happens to have
better in/out
I think this behavior should be reverted and if the new behavior
something that should be opt-in via an option, if at all.
Intrusive behavior changes like this should at the very least have been
signalled via a clear, standalone CSR and not buried in what looked like
a bug fix.
/Claes
On
I’m using the tool I wrote to compress directories with thousands of log files.
The standard zip utility (as well as my utility when run with JDK 12) takes up
to an hour of user time to create the archive, on our server class 40+ core
servers this is reduced to 1–2 minutes.
So while I
One of the motivations back then is to speed up the performance of accessing
those entries, means you don't have to deflate/inflate those new/updated
entries
during the lifetime of that zipfilesystem. Those updated entries only
get compressed
when go to storage. So the regression is more
Filed: https://bugs.openjdk.java.net/browse/JDK-8222532
I've marked the bug as potentially affecting the upcoming 11.0.3
release, since the issue that caused this regression is purportedly
being backported to that version.
/Claes
On 2019-04-16 14:21, Claes Redestad wrote:
Both before and
Both before and after this regression, it seems the default behavior is
not to use a temporary file (until ZFS.sync(), which writes to a temp
file and then moves it in place, but that's different from what happens
with the useTempFile option enabled). Instead entries (and the backing
zip file
On 15/04/2019 14:32, Lennart Börjeson wrote:
:
Previously, the deflation was done when in the call to Files.copy, thus
executed in parallel, and the final ZipFileSystem.close() didn't do anything
much.
Can you submit a bug? When creating/updating a zip file with zipfs then
the closing the
Hi Claes,
will you open a bug for this?
Thanks
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Lennart Börjeson
> Sent: Dienstag, 16. April 2019 09:05
> To: Claes Redestad
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: ZipFileSystem p
Very good, thank you!
Also note that the "new" implementation also requires *a lot* more heap, since
all *uncompressed* file content is copied to the heap before deflating.
Best regards,
/Lennart Börjeson
> 15 apr. 2019 kl. 18:34 skrev Claes Redestad :
>
> Hi Lennart,
>
> I can reproduce
Hi Lennart,
I can reproduce this locally, and have narrowed down to
https://bugs.openjdk.java.net/browse/JDK-8034802 as the cause.
As you say the compression is deferred to ZipFileSystem.close() now,
whereas previously it happened eagerly. We will have to analyze the
changes more in-depth to
I have made a small command-line utility which creates zip archives by
compressing the input files in parallel.
I do this by calling Files.copy(input, zipOutputStream) in a parallel Stream
over all input files.
I have run this with Java 1.8, 9, 10, and 11, on both my local laptop and on
Hi Lennart,
sure, excited to hear it...
Thanks
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Lennart Börjeson
> Sent: Freitag, 12. April 2019 14:26
> To: core-libs-dev@openjdk.java.net
> Subject: ZipFileSystem performance regression
>
> I've found what I
On 2019-04-12 14:25, Lennart Börjeson wrote:
Is this the right forum to report such issues?
I'm sure there are some friendly OpenJDK contributors around
these parts who'd be interested in a description and a reproducer.
/Claes
20 matches
Mail list logo
