On Wed, 15 Feb 2023 11:44:17 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> Strin
On Wed, 15 Feb 2023 11:44:17 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> Strin
On Wed, 15 Feb 2023 11:32:32 GMT, Lance Andersen wrote:
>> The habit of opening resources in a TwR is hard to break, but I guess it's
>> ok for a test like this. I have inlined the method and removed the TwR.
>
>> The habit of opening resources in a TwR is hard to break, but I guess it's
>> ok
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Wed, 15 Feb 2023 09:55:04 GMT, Eirik Bjorsnos wrote:
> The habit of opening resources in a TwR is hard to break, but I guess it's ok
> for a test like this. I have inlined the method and removed the TwR.
Agree, thanks for addressing the suggestion as it makes the test cleaner given
expects/
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Tue, 14 Feb 2023 23:12:38 GMT, Lance Andersen wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Prefer expectThrows with asserts over test annotation regex
>
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryN
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Tue, 14 Feb 2023 11:49:23 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> Strin
On Tue, 14 Feb 2023 11:21:36 GMT, Lance Andersen wrote:
>> The message is already validated using `expectedExceptionsMessageRegExp` in
>> the `@Test` annotation.
>>
>> Would you prefer if I use expectThrows instead, or perhaps inline the
>> `BAD_ENTRY_NAME_OR_COMMENT` constant as a literal?
>
On Tue, 14 Feb 2023 08:34:15 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> Strin
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Tue, 14 Feb 2023 08:47:15 GMT, Eirik Bjorsnos wrote:
>> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 90:
>>
>>> 88: expectedExceptionsMessageRegExp = BAD_ENTRY_NAME_OR_COMMENT)
>>> 89: public void shouldRejectInvalidName() throws IOException {
>>>
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Mon, 13 Feb 2023 20:20:22 GMT, Lance Andersen wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert accidental removal of UTF8ZipCoder.compare
>
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComme
On Mon, 13 Feb 2023 20:00:51 GMT, Lance Andersen wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert accidental removal of UTF8ZipCoder.compare
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Thu, 9 Feb 2023 12:07:04 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Thu, 9 Feb 2023 11:46:42 GMT, Eirik Bjorsnos wrote:
> > In addition to - or instead of - an `equals` shortcut then if coders are
> > the same we could use `ArraysSupport.mismatch` which should get similar
> > speed and help more generally.
>
> ..and if String had (an optimized) mismatch met
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Thu, 9 Feb 2023 11:39:18 GMT, Claes Redestad wrote:
> Yes, I'll file a PR to see if we can make `startsWith` a bit sharper
Thanks! I pushed the change to ZipCoder.compare.
> In addition to - or instead of - an `equals` shortcut then if coders are the
> same we could use `ArraysSupport.misma
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Thu, 9 Feb 2023 11:17:54 GMT, Eirik Bjorsnos wrote:
> It helps... a lot!
I guess an update to String.startsWith should be handled separately from this
PR.
If startsWith will be optimized, then I'm happy to update this PR to use
startsWith as you suggested. Then ZipCoder will speed up for f
On Thu, 9 Feb 2023 11:07:17 GMT, Claes Redestad wrote:
> Could be interesting to see if special-casing `startsWith` to call `equals`
> when possible would help:
It helps... a lot!
Benchmark (size) Mode CntScore Error Units
ZipFileGetEntry.getEntryHit
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Thu, 9 Feb 2023 10:05:06 GMT, Claes Redestad wrote:
> Should be a win and avoids the need for a new mismatch method here.
Interestingly, this is not a win:
PR:
Benchmark (size) Mode CntScore Error Units
ZipFileGetEntry.getEntryHit 512 avgt
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Wed, 8 Feb 2023 17:11:19 GMT, Claes Redestad wrote:
> Great! Extending coverage to provoke the issue on most charsets is good, and
> it should guard UTF-8 from regressing too - no?
It also guards UTFZipCoder from this particular regression, yes.
-
PR: https://git.openjdk.org/jd
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Wed, 8 Feb 2023 15:31:15 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Wed, 8 Feb 2023 15:31:15 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Wed, 8 Feb 2023 15:31:15 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Wed, 8 Feb 2023 15:21:23 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Tue, 7 Feb 2023 13:23:26 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Wed, 8 Feb 2023 11:57:16 GMT, Claes Redestad wrote:
> > > Seems there's a possible real test failure lurking here, might be
> > > intermittent since it only showed on one platform:
> >
> >
> > Did you get this from GHA somehow? Do you happen to know the platform,
> > timezone and encoding
On Wed, 8 Feb 2023 11:32:02 GMT, Eirik Bjorsnos wrote:
> > Seems there's a possible real test failure lurking here, might be
> > intermittent since it only showed on one platform:
>
> Did you get this from GHA somehow? Do you happen to know the platform,
> timezone and encoding used?
Yes, cli
On Tue, 7 Feb 2023 22:52:13 GMT, Claes Redestad wrote:
> Seems there's a possible real test failure lurking here, might be
> intermittent since it only showed on one platform:
Did you get this from GHA somehow? Do you happen to know the platform, timezone
and encoding used?
-
PR:
On Tue, 7 Feb 2023 13:23:26 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
This is still on my list to review will get to it in the next day or so
On Feb 7, 2023, at 8:23 AM, Eirik Bjorsnos
mailto:d...@openjdk.org>> wrote:
After finding a hash match, getEntryPos needs to compare the lookup name up to
the encoded entry name in the CEN. This comparison is done by decodi
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Mon, 6 Feb 2023 16:14:14 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Mon, 6 Feb 2023 15:56:09 GMT, Claes Redestad wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Spelling fix in test data for non-ascii latin1 string
>
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrCo
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Mon, 6 Feb 2023 15:21:10 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Mon, 6 Feb 2023 15:21:10 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Mon, 6 Feb 2023 15:14:37 GMT, Eirik Bjorsnos wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Spelling fix in test data for non-ascii latin1 string
>
> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java l
On Mon, 6 Feb 2023 15:17:14 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Mon, 6 Feb 2023 11:56:22 GMT, Eirik Bjorsnos wrote:
>> src/java.base/share/classes/java/lang/System.java line 2671:
>>
>>> 2669: if (false) {
>>> 2670: // Arrays.mismatch without the range checks (~5%
>>> faster micro getEntryHit)
>>> 2671:
On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos wrote:
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> AP
On Mon, 6 Feb 2023 12:01:19 GMT, Eirik Bjorsnos wrote:
>> Nice, I have updated the PR such that the new shared secret is replaced with
>> using getBytesNoRepl instead. If there is a performance difference, it seems
>> to hide in the noise.
>>
>> I had expected such a regression to be caught by
On Mon, 30 Jan 2023 14:20:58 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> Strin
On Mon, 6 Feb 2023 14:27:36 GMT, Claes Redestad wrote:
>> Interesting. Would be nice to solve this in the JIT!
>>
>> This disabled code got deleted in my last commit, but it seems like you have
>> a good analysis so we can let it go now.
>
> Right. I might have fumbled this experiment a bit, an
On Mon, 6 Feb 2023 11:47:42 GMT, Eirik Bjorsnos wrote:
>> src/java.base/share/classes/java/lang/System.java line 2668:
>>
>>> 2666: @Override
>>> 2667: public int mismatchUTF8(String str, byte[] b, int
>>> fromIndex, int toIndex) {
>>> 2668: byte[] encode
On Sun, 5 Feb 2023 22:13:50 GMT, Claes Redestad wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos wrote:
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> AP
61 matches
Mail list logo
