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 thi
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 performance regression
>
>
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 fi
On 15/04/2019 08:48, David Holmes wrote:
On 15/04/2019 5:34 pm, Patrick Zhang OS wrote:
Removed it.
http://cr.openjdk.java.net/~qpzhang/8222334/webrev.03/jdk.changeset
By the way, could you please sponsor to push it once approved? thanks
in advance.
Sure - if the core-libs person who also r
On 16/04/2019 5:40 pm, Alan Bateman wrote:
On 15/04/2019 08:48, David Holmes wrote:
On 15/04/2019 5:34 pm, Patrick Zhang OS wrote:
Removed it.
http://cr.openjdk.java.net/~qpzhang/8222334/webrev.03/jdk.changeset
By the way, could you please sponsor to push it once approved? thanks
in advance.
Patrick,
Sorry should have picked up on this earlier. Can you please update the
following two tests to add a test for '0' as appropriate:
./jdk/tools/launcher/TooSmallStackSize.java
./hotspot/jtreg/runtime/Thread/TooSmallStackSize.java
Thanks,
David
On 16/04/2019 5:47 pm, David Holmes wrote:
Sure I will add this, and fix the intention mentioned by Alan.
Regards
Patrick
-Original Message-
From: David Holmes
Sent: Tuesday, April 16, 2019 4:17 PM
To: Patrick Zhang OS
Cc: Alan Bateman ; core-libs-dev
Subject: Re: RFR: 8222334: java -Xss0 triggers StackOverflowError
Patrick,
Hi David,
Please see my updates, the two '0' size test cases. I have run them with jtreg
on jdk13 + linux + x86/aarch64 systems respectively, all passed.
http://cr.openjdk.java.net/~qpzhang/8222334/webrev.04
Regards
Patrick
-Original Message-
From: core-libs-dev On Behalf Of
Patrick
Hi Patrick,
On 16/04/2019 7:42 pm, Patrick Zhang OS wrote:
Hi David,
Please see my updates, the two '0' size test cases. I have run them with jtreg
on jdk13 + linux + x86/aarch64 systems respectively, all passed.
http://cr.openjdk.java.net/~qpzhang/8222334/webrev.04
Thanks. Please update copy
Done. http://cr.openjdk.java.net/~qpzhang/8222334/webrev.05
Regards
Patrick
-Original Message-
From: David Holmes
Sent: Tuesday, April 16, 2019 6:34 PM
To: Patrick Zhang OS
Cc: core-libs-dev
Subject: Re: RFR: 8222334: java -Xss0 triggers StackOverflowError
Hi Patrick,
On 16/04/201
Thanks Patrick! Changes pushed.
David
On 16/04/2019 8:44 pm, Patrick Zhang OS wrote:
Done. http://cr.openjdk.java.net/~qpzhang/8222334/webrev.05
Regards
Patrick
-Original Message-
From: David Holmes
Sent: Tuesday, April 16, 2019 6:34 PM
To: Patrick Zhang OS
Cc: core-libs-dev
Subje
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 syst
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 after
On 4/12/19 4:51 AM, Andy Herrick wrote:
On 4/11/2019 6:06 PM, semyon.sadet...@oracle.com wrote:
On 4/11/19 12:05 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
[1] htt
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 li
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 understa
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 2019-0
Hi Joe,
Overall, I think the updates look OK. One minor correction/cleanup for before
you push is in the XMLEntityManager line 3078/79 to move back the else to 3078
No need to update the webrev
HTH
Best
Lance
> On Apr 15, 2019, at 3:46 PM, Joe Wang wrote:
>
> Please review an update from Xe
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 co
Hi,
please review a fix for an issue with zipfs/jarfs regarding multi-release jars.
The issue is observed when an mr-jar does have entries for certain files in the
versioned subfolders but not in the main tree. This should be allowed as per
JEP 238 [0]. So, say, if a jar file contains an entry
Hi,
I also think the regression should be repaired and maybe we can have an option
like "lazy compress" to avoid compression on write but defer it to zipfs
closing time.
It should also be possible to parallelize deflation during close, shouldn't it?
Best regards
Christoph
> -Original Mess
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 w
Thanks Lance! Pushed after changing 3078/79 back to 3078.
Best,
Joe
On 4/16/19, 1:14 PM, Lance Andersen wrote:
Hi Joe,
Overall, I think the updates look OK. One minor correction/cleanup
for before you push is in the XMLEntityManager line 3078/79 to move
back the else to 3078
No need to u
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
Hi Per,
While testing different JVMs I realized that it's fixed in openjdk 11,
e.g. openjdk version "11.0.1" 2018-10-16 LTS (zulu build), maybe by this
commit: https://hg.openjdk.java.net/jdk/jdk/rev/6464882498b5
That's great to know, but is it worth updating the javadocs of older
versions?
To re
25 matches
Mail list logo
