On Thu, 9 Feb 2023 12:54:42 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> AttributeElement.Kind removal (#48)
>
>
On Tue, 14 Feb 2023 20:08:47 GMT, Alan Bateman wrote:
>I don't think we have a good handle on the issue. It's clear that this zlib
>implementation is a bit different but I'm concerned that your proposed change
>to the test is masking an issue. I say this because the check method is
>changed
> Proceeding down the line of FDLIBM functions to be ported, next up are asin,
> acos, and atan.
>
> Diffs of the various versions will follow in a separate message.
>
> There were no unusual coding idioms encountered in porting these methods.
Joe Darcy has updated the pull request
> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to
> refactor the regression tests a bit to reduce duplication, but the actual
> ports should be ready for review.
>
> Diff'ing the ports as before, original vs transliteration port:
>
>
> $ diff -w Hyperbolic.c
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
>>
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 22:41:47 GMT, Claes Redestad wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Last of review comments
>
> I've started tier1-5 testing internally. Will let you know if we find any
> issues.
On Tue, 14 Feb 2023 19:30:27 GMT, Mandy Chung wrote:
>> `LambdaForm` declares int constants for `BasicType::ordinal` to workaround
>> JDK-8161245. Now these int constants are no longer needed.This removes
>> these int constants and reference `BasicType` enums directly.
>
> Mandy Chung
On Tue, 14 Feb 2023 18:22:32 GMT, Scott Gibbons wrote:
>> Added code for Base64 acceleration (encode and decode) which will accelerate
>> ~4x for AVX2 platforms.
>>
>> Encode performance:
>> **Old:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score Error
>> Units
On Mon, 13 Feb 2023 19:35:52 GMT, Mandy Chung wrote:
> I overlooked in the fix for JDK-8297757 that it should have passed the
> declaring class of the static fields rather than the reference class passed
> to `Lookup::findStaticVarHandle`.
This pull request has now been integrated.
On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev wrote:
>> clamp() methods added to Math and StrictMath
>>
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long`
>> value and safely clamps it to an `int` range. Other overloads work with a
>> particular type (long, float
On Mon, 13 Feb 2023 19:35:52 GMT, Mandy Chung wrote:
> I overlooked in the fix for JDK-8297757 that it should have passed the
> declaring class of the static fields rather than the reference class passed
> to `Lookup::findStaticVarHandle`.
Marked as reviewed by psandoz (Reviewer).
On Tue, 14 Feb 2023 19:30:19 GMT, Severin Gehwolf wrote:
>> Could I please get a review of this trivial comment-only change?
>> `imageFile.hpp`
>> describes some properties of the jimage file `lib/modules`. However, I don't
>> think
>> the comment example matches current code in the JDK.
>>
On Tue, 14 Feb 2023 20:13:03 GMT, Tagir F. Valeev wrote:
> Finally, I find it extremely strange to use var to hide the type and name the
> variable as `longValue2`, encoding the type inside variable name.
This is just an example name to document the type of the var for this post.
On Wed, 8 Feb 2023 23:07:14 GMT, Ian Graves wrote:
>> This is an approach to adding a flag to jlink that will allow --compress to
>> take the same types of arguments as jmod, thus bringing the two into
>> alignment. This likely requires a CSR and a discussion on whether we should
>> deprecate
On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev wrote:
>> clamp() methods added to Math and StrictMath
>>
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long`
>> value and safely clamps it to an `int` range. Other overloads work with a
>> particular type (long, float
On Tue, 7 Feb 2023 07:07:54 GMT, Alan Bateman wrote:
>>> Hi @AlanBateman ,
>>> with latest changes (doing inflate/deinflate) test passes over s390 and x86
>>> as well. Please take a look now.
>>
>> Good. One thing to try is to just deflate/inflate into out1/out2, no need
>> for the
On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev wrote:
>> clamp() methods added to Math and StrictMath
>>
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long`
>> value and safely clamps it to an `int` range. Other overloads work with a
>> particular type (long, float
On Tue, 14 Feb 2023 10:50:12 GMT, Jorn Vernee wrote:
>> Mandy Chung has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>> commits
On Tue, 14 Feb 2023 11:16:26 GMT, Sergey Tsypanov wrote:
>> Mandy Chung has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>>
> `LambdaForm` declares int constants for `BasicType::ordinal` to workaround
> JDK-8161245. Now these int constants are no longer needed.This removes
> these int constants and reference `BasicType` enums directly.
Mandy Chung has updated the pull request with a new target base due to a
On Tue, 14 Feb 2023 18:10:11 GMT, Jim Laskey wrote:
>> Got it. How about we change this comment from:
>>
>> // - Even though ATTRIBUTE_END is used to mark the end of the attribute
>> stream,
>> // streams will contain zero byte values to represent lesser
>> significant bits.
>> //
On Tue, 14 Feb 2023 17:18:00 GMT, Jim Laskey wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>>
> Could I please get a review of this trivial comment-only change?
> `imageFile.hpp`
> describes some properties of the jimage file `lib/modules`. However, I don't
> think
> the comment example matches current code in the JDK.
>
On Tue, 14 Feb 2023 18:56:29 GMT, Roger Riggs wrote:
>> It can be difficult to find the cause of calls to
>> `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java
>> runtime exits.
>> The status value and stack trace are logged using the System Logger named
>>
On Tue, 14 Feb 2023 18:22:32 GMT, Scott Gibbons wrote:
>> Added code for Base64 acceleration (encode and decode) which will accelerate
>> ~4x for AVX2 platforms.
>>
>> Encode performance:
>> **Old:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score Error
>> Units
> It can be difficult to find the cause of calls to
> `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java
> runtime exits.
> The status value and stack trace are logged using the System Logger named
> `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
> Added code for Base64 acceleration (encode and decode) which will accelerate
> ~4x for AVX2 platforms.
>
> Encode performance:
> **Old:**
>
> Benchmark (maxNumBytes) Mode Cnt Score Error
> Units
> Base64Encode.testBase64Encode 1024 thrpt3
On Tue, 14 Feb 2023 18:01:44 GMT, Severin Gehwolf wrote:
>> I meant that an attribute can have zeros in the non-header portion of the
>> attribute data.
>
> Got it. How about we change this comment from:
>
> // - Even though ATTRIBUTE_END is used to mark the end of the attribute
> stream,
>
On Tue, 14 Feb 2023 17:15:28 GMT, Daniel Fuchs wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add an @implNote to Runtime.exit to describe the java.lang.Runtime logging.
>
>
On Tue, 14 Feb 2023 17:17:53 GMT, Jim Laskey wrote:
>> To me it sounded like it wanted to say: Since the `ATTRIBUTE_END` isn't a
>> full byte (only 5 bits in a byte), it might be represented as a non-zero
>> value. For example a byte containing `0x07` would equally be `ATTRIBUTE_END`
>> as
On Tue, 14 Feb 2023 15:19:34 GMT, Claes Redestad wrote:
>> Why? There is no performance difference and the intent is clear. Is this
>> just a "style" thing?
>
> I think with `lessEqual` we'll jump to `L_tailProc` for the final 32-byte
> chunk in inputs that are divisible by 32 (starting from
On Tue, 14 Feb 2023 15:03:49 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2658:
>>
>>> 2656: // Check for buffer too small (for algorithm)
>>> 2657: __ subl(length, 0x2c);
>>> 2658: __ jcc(Assembler::lessEqual, L_tailProc);
>>
>> This could be
Hi!
CorruptedZipFiles could benefit from some modernization and a conversion to
testNG:
https://github.com/openjdk/jdk/pull/12563
Thanks,
Eirik.
On Tue, 14 Feb 2023 17:10:32 GMT, Severin Gehwolf wrote:
>> @JimLaskey OK. Perhaps we can be clearer what is meant here exactly. I was
>> having a hard time deciphering this. It does say `stream will contain zero
>> byte values to represent lesser significant bits`. **What** are "byte values
On Tue, 14 Feb 2023 14:46:58 GMT, Severin Gehwolf wrote:
>> Could I please get a review of this trivial comment-only change?
>> `imageFile.hpp`
>> describes some properties of the jimage file `lib/modules`. However, I don't
>> think
>> the comment example matches current code in the JDK.
>>
On Tue, 14 Feb 2023 16:59:03 GMT, Severin Gehwolf wrote:
>> src/java.base/share/native/libjimage/imageFile.hpp line 218:
>>
>>> 216: // Notes:
>>> 217: // - Even though ATTRIBUTE_END is used to mark the end of the
>>> attribute stream,
>>> 218: // streams will contain non-zero byte
On Tue, 14 Feb 2023 16:47:15 GMT, Jim Laskey wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>>
On Tue, 14 Feb 2023 14:46:58 GMT, Severin Gehwolf wrote:
>> Could I please get a review of this trivial comment-only change?
>> `imageFile.hpp`
>> describes some properties of the jimage file `lib/modules`. However, I don't
>> think
>> the comment example matches current code in the JDK.
>>
> It can be difficult to find the cause of calls to
> `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java
> runtime exits.
> The status value and stack trace are logged using the System Logger named
> `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
On Tue, 14 Feb 2023 10:40:31 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>>
On Sun, 12 Feb 2023 09:34:37 GMT, Alan Bateman wrote:
>>> It seems a bit fragile to be parsing the output of `fsutil volume diskFree`
>>> as the output seems to vary by Windows releases and maybe configuration. So
>>> minimally, I think it should be changed to use ProcessTools so that the
>>>
On Tue, 29 Nov 2022 00:56:58 GMT, Brian Burkhalter wrote:
> `java.io.InputStream::transferTo` could conceivably return a negative value
> if the count of bytes transferred overflows a `long`. Modify the method to
> limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.
This
On Tue, 14 Feb 2023 15:03:50 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2699:
>>
>>> 2697: __ addptr(dest, 0x18);
>>> 2698: __ subl(length, 0x20);
>>> 2699: __ jcc(Assembler::lessEqual, L_tailProc);
>>
>> This could be Assembler::less instead of
On Tue, 14 Feb 2023 01:48:37 GMT, Sandhya Viswanathan
wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add URL to microbenchmark
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2399:
>
>> 2397:
On Tue, 14 Feb 2023 10:40:31 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>>
> Could I please get a review of this trivial comment-only change?
> `imageFile.hpp`
> describes some properties of the jimage file `lib/modules`. However, I don't
> think
> the comment example matches current code in the JDK.
>
On Tue, 14 Feb 2023 14:07:22 GMT, Raffaello Giulietti
wrote:
>> Sorry, I overlooked those checks two times :)
>>
>> How about adding a moderate path like
>>
This fixes the linked issue by trimming the caller of a frame to be deoptimized
back to its `unextended_sp` iff it is compiled. The creation of the section
`dead after deoptimization` shown in the attachment
On Tue, 14 Feb 2023 08:02:08 GMT, Andriy Plokhotnyuk wrote:
>> A reimplementation of `BigDecimal.[double|float]Value()` to enhance
>> performance, avoiding an intermediate string and its subsequent parsing on
>> the slow path.
>
> Sorry, I overlooked those checks two times :)
>
> How about
On Tue, 14 Feb 2023 10:40:31 GMT, Alan Bateman wrote:
> Can you update the end date of the copyright headers as this is the first
> change in 2023. imageFile.cpp by missed by the other change so it could be
> done here too.
Absolutely! Thanks for the review.
-
PR:
On Mon, 13 Feb 2023 22:03:14 GMT, Joe Darcy wrote:
> Proceeding down the line of FDLIBM functions to be ported, next up are asin,
> acos, and atan.
>
> Diffs of the various versions will follow in a separate message.
>
> There were no unusual coding idioms encountered in porting these
On Tue, 14 Feb 2023 07:45:07 GMT, Alan Bateman wrote:
>> FINE is not a level supported by the System.Logger, it is the level to which
>> DEBUG is mapped when the backend is java.util.logging. I suggest to remove
>> FINE from this description and add an `{@link Loger.Level#DEBUG DEBUG}`
>>
On Mon, 13 Feb 2023 19:35:52 GMT, Mandy Chung wrote:
> I overlooked in the fix for JDK-8297757 that it should have passed the
> declaring class of the static fields rather than the reference class passed
> to `Lookup::findStaticVarHandle`.
Looks right and you've added good test coverage.
> 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
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 {
>>>
On Mon, 13 Feb 2023 22:05:15 GMT, Mandy Chung wrote:
> `LambdaForm` declares int constants for `BasicType::ordinal` to workaround
> JDK-8161245. Now these int constants are no longer needed.This removes
> these int constants and reference `BasicType` enums directly.
On Mon, 13 Feb 2023 22:05:15 GMT, Mandy Chung wrote:
> `LambdaForm` declares int constants for `BasicType::ordinal` to workaround
> JDK-8161245. Now these int constants are no longer needed.This removes
> these int constants and reference `BasicType` enums directly.
On Fri, 10 Feb 2023 23:18:47 GMT, Claes Redestad wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add URL to microbenchmark
>
> Marked as reviewed by redestad (Reviewer).
> @cl4es Can you please initiate the
On Mon, 13 Feb 2023 14:12:15 GMT, Severin Gehwolf wrote:
> Could I please get a review of this trivial comment-only change?
> `imageFile.hpp`
> describes some properties of the jimage file `lib/modules`. However, I don't
> think
> the comment example matches current code in the JDK.
>
> 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
On Mon, 13 Feb 2023 16:57:17 GMT, Severin Gehwolf wrote:
> The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds.
> However,
> the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent
> `kind`), might
> be non-zero in the lower 3 bits (values up to `0x07`
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
>>
On Mon, 13 Feb 2023 16:57:17 GMT, Severin Gehwolf wrote:
> The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds.
> However,
> the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent
> `kind`), might
> be non-zero in the lower 3 bits (values up to `0x07`
On Mon, 13 Feb 2023 19:50:24 GMT, Alan Bateman wrote:
> The change looks good, I'm just curious whether you observed a crash or
> whether this was noticed by inspection.
Noticed by exploration. Changed the java code on the jlink side and observed
the crash.
-
PR:
On Mon, 13 Feb 2023 16:43:12 GMT, Eirik Bjorsnos wrote:
> Case-insensitive regionMatches could be improved by using
> ArraysSupport.mismatch to skip over long common substrings:
I considered this but saw regressions similar to what you're getting for size =
6 and backed off. I think this
> 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
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
>
>
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
On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti
wrote:
> A reimplementation of `BigDecimal.[double|float]Value()` to enhance
> performance, avoiding an intermediate string and its subsequent parsing on
> the slow path.
Sorry, I failed to recognize those checks two times :)
How about
70 matches
Mail list logo
