On Tue, 1 Oct 2024 16:08:56 GMT, Brian Burkhalter wrote:
>> Improve the first sentences of the three `FileInputStream` constructors, in
>> particular removing the term "connection."
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revis
On Wed, 2 Oct 2024 02:13:40 GMT, David Holmes wrote:
> Nothing further from me on the VM side. Just a couple of minor nits.
>
> Thanks
I've pushed another commit to address the nits.
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/21048#issuecomment-2387676650
> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS
> archive;
> during run time, full module graph will not be used.
>
> With this patch, the full module graph will be included in the CDS archive
>
On Tue, 24 Sep 2024 14:56:19 GMT, Maurizio Cimadamore
wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.bas
> Some DirectCodeBuilder related optimizations to improve startup and running
> performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load
> Some DirectCodeBuilder related optimizations to improve startup and running
> performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load
On Sun, 29 Sep 2024 17:44:30 GMT, Attila Szegedi wrote:
> Fixes a regression with #17818 where `ArrayList.subList(…).sort()` started
> incrementing `ArrayList.modCount` resulting in some cases throwing a
> `ConcurrentModificationException` where none was thrown before.
>
> This change keeps th
On Mon, 30 Sep 2024 23:36:35 GMT, Chen Liang wrote:
> Perform validation of local variable slots, multinewarray dimension, iinc
> value and specify these validations are performed. Specify these exception
> behaviors for sipush and bipush as well.
>
> This validation avoids using invalid value
On Mon, 30 Sep 2024 23:36:35 GMT, Chen Liang wrote:
> Perform validation of local variable slots, multinewarray dimension, iinc
> value and specify these validations are performed. Specify these exception
> behaviors for sipush and bipush as well.
>
> This validation avoids using invalid value
On Tue, 1 Oct 2024 17:30:10 GMT, Calvin Cheung wrote:
>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS
>> archive;
>> during run time, full module graph will not be used.
>>
>> With this patch
On Tue, 1 Oct 2024 17:30:10 GMT, Calvin Cheung wrote:
>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS
>> archive;
>> during run time, full module graph will not be used.
>>
>> With this patch
On Mon, 30 Sep 2024 15:26:07 GMT, Henry Jen wrote:
>> Hello Henry, I think this `-k` option help text would need a slight
>> modification. Right now it states that if a file appears more than once in
>> an archive, then this setting this flag will not overwrite the earlier
>> copies. In realit
On Mon, 23 Sep 2024 12:06:51 GMT, Jorn Vernee wrote:
>>> I think "can not be determined" just begs questions. Is this a JDK
>>> limitation, something I'm doing wrong, or something else, ... if you see
>>> what I mean.
>>
>> I think saying 'no caller class on the stack' has the same effect thou
On Tue, 24 Sep 2024 14:56:19 GMT, Maurizio Cimadamore
wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.bas
On Mon, 23 Sep 2024 21:06:12 GMT, Maurizio Cimadamore
wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.bas
On Tue, 24 Sep 2024 14:48:50 GMT, Jorn Vernee wrote:
>> The "stack" is exposed in the API with StackWalker, Thread::getStackTrace
>> and other APIs. For CS and restricted methods then I think we are trying to
>> convey that there are no Java frames on the caller stack. Several existing
>> CS A
> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> The implementation of java.lang.invoke uses SoftReferences so that unused
> MethodHandles, LambdaForms, etc, can be garbage collected.
>
> However, if we want to store j
On Mon, 30 Sep 2024 15:14:31 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which updates code and tests in `java.base` to
> consistently use `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when
> referring to the JVM's maximum array size implementation limit. Currently,
>
On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates code and tests in `java.base` to
>> consistently use `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH`
>> when referring to the JVM's maximum array size implementation limit.
>> Currentl
> This PR support a -k, --keep options like tar that allows jar to avoid
> override existing files.
Henry Jen has updated the pull request incrementally with one additional commit
since the last revision:
More review comments
-
Changes:
- all: https://git.openjdk.org/jdk/pull/
On Tue, 1 Oct 2024 08:20:43 GMT, Matthias Baesken wrote:
>> `jni_md.h` is shipped as part of every JDK distribution - this change does
>> NOT belong in that file.
>
>> `jni_md.h` is shipped as part of every JDK distribution - this change does
>> NOT belong in that file.
>
> Hi David, should I
On Tue, 1 Oct 2024 17:49:12 GMT, Maurizio Cimadamore
wrote:
>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some
>> round of adaptation.
>> Adapting a var handle results in a so called *indirec
On Mon, 19 Aug 2024 21:47:23 GMT, Sandhya Viswanathan
wrote:
> Currently the rearrange and selectFrom APIs check shuffle indices and throw
> IndexOutOfBoundsException if there is any exceptional source index in the
> shuffle. This causes the generated code to be less optimal. This PR modifies
Please review this PR which modifies a suspicious check in the fallback of
`Locale.getDisplayName(Locale inLocale)`.
As a fallback, a hard coded pattern is used. The previous code outputted the
qualifiers if the `displayNames` array had length greater than 2. Just a few
lines above, the array i
On Mon, 30 Sep 2024 11:38:20 GMT, Lance Andersen wrote:
>> I follow existing pattern with short status update. Open to suggestions.
>
> Perhaps something like:
>
> ` \ \ file: {0} exists, skipped`
Use this for now to be more close to current style,
`\ \ skipped: {0} exists`
Was thinki
> Some DirectCodeBuilder related optimizations to improve startup and running
> performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load
On Tue, 1 Oct 2024 14:21:19 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
> Some DirectCodeBuilder related optimizations to improve startup and running
> performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load
On Mon, 30 Sep 2024 14:03:15 GMT, Johny Jose wrote:
> Timezone data 2024b changes
src/java.base/share/classes/java/time/ZoneId.java line 189:
> 187: * {@link #of(String, Map)} factory method.
> 188: *
> 189: * This map contains a mapping of the IDs that is in line with TZDB
> 2
On Mon, 30 Sep 2024 14:03:15 GMT, Johny Jose wrote:
> Timezone data 2024b changes
src/java.base/share/classes/java/time/ZoneId.java line 191:
> 189: * This map contains a mapping of the IDs that is in line with TZDB
> 2024b and
> 190: * later, where 'EST', 'MST' and 'HST' map to IDs
On Tue, 1 Oct 2024 09:51:27 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new two vector permutation APIs.
>>
>>
>> Declaration:-
>> Vector.selectFrom(Vector v1, Vector v2)
>>
>>
>> Semantics:-
>>
On Fri, 27 Sep 2024 18:08:54 GMT, Justin Lu wrote:
>> Please review this PR which removes usages of Applet within the corelibs
>> tests.
>>
>> Most changes are removed comments/updated var names. The JBS issue lists
>> more files than the ones included in this pull request, please see the
>>
On Tue, 1 Oct 2024 09:53:02 GMT, Jatin Bhateja wrote:
>> Thanks for the example. Yes, you have a point there. So we would need to do:
>>src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH -
>> 1).toShuffle(), src2);
>
>> This could instead be: src1.rearrange(this.lanewise(VectorOp
On Tue, 1 Oct 2024 17:49:12 GMT, Maurizio Cimadamore
wrote:
>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some
>> round of adaptation.
>> Adapting a var handle results in a so called *indirec
On Tue, 1 Oct 2024 12:22:34 GMT, Aleksey Shipilev wrote:
>> This fixes a format string issue.
>>
>> In the error report it was reported : 'The compiler should be able to catch
>> this if JLI_ReportErrorMessageSys was declared with something like
>> __attribute__ ((format (printf, 1, 2))).'
>>
On Tue, 1 Oct 2024 17:44:27 GMT, Jorn Vernee wrote:
>> I believe `EXCLUDE` is what I was reaching out for
>
> I think EXCLUDE would work, yes. True about CompileCommand having a global
> effect, so that won't work. (With a CompilerDirective file we could be more
> precise, not sure if it's wort
On Tue, 1 Oct 2024 16:22:36 GMT, Maurizio Cimadamore
wrote:
>> The issue with using a compile command is that it will then work globally.
>> So the benchmark would not really test much - besides checking that var
>> handle access is slow when `asType` cannot inline. What I was trying to do
>>
> The fix for JDK-8331865 introduced an accidental performance regression.
> The main issue is that now *all* memory segment var handles go through some
> round of adaptation.
> Adapting a var handle results in a so called *indirect* var handle.
> When an indirect var handle is called through a *v
Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8341285)
which clarifies that a Locale sensitive service provider can be deployed as a
module.
This mainly follows the same format as the work done for
[JDK-8340404](https://bugs.openjdk.org/browse/JDK-8340404), by providing a
> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS
> archive;
> during run time, full module graph will not be used.
>
> With this patch, the full module graph will be included in the CDS archive
>
On Tue, 1 Oct 2024 07:15:13 GMT, Eirik Bjørsnøs wrote:
> Is `compiler` label needed? The `jar` tool belongs in `core-libs`, right?
> This PR does not seem to touch anything in the compiler area?
Automatically added by the bot. I agree it's not related to compiler at all.
I'll manually remove i
On Sun, 29 Sep 2024 06:43:42 GMT, Alan Bateman wrote:
>> Why does it need to clear `moduleToReader` only for app loader and not for
>> platform loader? Is it because the `moduleToReader` for the app loader may
>> contain reference to jar files that indirectly references some file system
>> obj
On Sun, 29 Sep 2024 04:11:53 GMT, Ioi Lam wrote:
>> It should work because the jmod file won't be added to the `module_paths`.
>
> In my scenario, will the FMG be used? If so, the program won't be able to
> load the code in mod2.jmod, so the behavior will be wrong. Could you add a
> test case f
On Mon, 30 Sep 2024 15:51:43 GMT, Lance Andersen wrote:
>> I considered that, but didn't implement it after confirmed other similar
>> options didn't display any warning.
>> I do think it make sense to show a warning when using an option not valid in
>> specific mode.
>
>> I considered that, bu
> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS
> archive;
> during run time, full module graph will not be used.
>
> With this patch, the full module graph will be included in the CDS archive
>
> Some DirectCodeBuilder related optimizations to improve startup and running
> performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load
On Tue, 1 Oct 2024 14:21:19 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
> Improve the first sentences of the three `FileInputStream` constructors, in
> particular removing the term "connection."
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8340229: Revert FIS(fdObj) change
-
Changes:
On Tue, 1 Oct 2024 15:46:49 GMT, Alan Bateman wrote:
>> Updated for the next commit.
>
> Did you push that commit? I don't see the update, the PR only has 1 commit.
I did just now.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21223#discussion_r1783138693
On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates code and tests in `java.base` to
>> consistently use `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH`
>> when referring to the JVM's maximum array size implementation limit.
>> Currentl
On Tue, 1 Oct 2024 16:07:35 GMT, Maurizio Cimadamore
wrote:
>> I see what you mean... I'll do some experiments and see how the current
>> annotation affects the benchmark - if at all.
>
> The issue with using a compile command is that it will then work globally. So
> the benchmark would not re
On Tue, 1 Oct 2024 16:20:02 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/util/zip/ZipError.java line 31:
>>
>>> 29: * Signals that an unrecoverable error has occurred.
>>> 30: *
>>> 31: * @deprecated ZipError is no longer used and is obsolete.
>>
>> I agree ZipError should be d
On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests to deprecate the unused class
>> `java.util.zip.ZipError` for removal.
>>
>> The class has been unsed by OpenJDK since the ZIP API was rewritten from
>> native to Java in JDK 9.
>>
>> I opted to n
> The fix for JDK-8331865 introduced an accidental performance regression.
> The main issue is that now *all* memory segment var handles go through some
> round of adaptation.
> Adapting a var handle results in a so called *indirect* var handle.
> When an indirect var handle is called through a *v
On Mon, 30 Sep 2024 16:11:14 GMT, sbgoog wrote:
>> FIleSystemPreferences.lockFile() catches an InterruptedException and just
>> returns false, forgetting to re-interrupt the current thread. This leaves
>> the caller with no way to observe that the thread was interrupted. This
>> change restore
On Tue, 1 Oct 2024 14:21:19 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
On Wed, 25 Sep 2024 14:50:12 GMT, Chen Liang wrote:
>> `MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is
>> unnecessary and can be scalarized manually. The removal of `ClassFile` class
>> is also slightly helpful for bootstrap by reducing class loading. Also
>> improve
On Tue, 1 Oct 2024 15:34:12 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Code simplification
>
> test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 69:
>
>> 67: @M
On Tue, 1 Oct 2024 16:12:57 GMT, Alan Bateman wrote:
>> Eirik Bjørsnøs 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 five additional
>> commit
On Tue, 1 Oct 2024 15:50:59 GMT, ExE Boss wrote:
>> Eirik Bjørsnøs 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 five additional
>> commits si
On Tue, 1 Oct 2024 10:18:15 GMT, Maurizio Cimadamore
wrote:
>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some
>> round of adaptation.
>> Adapting a var handle results in a so called *indirec
On Thu, 19 Sep 2024 22:12:58 GMT, Jonathan Gibbons wrote:
>> Nizar Benalla has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 28 commits:
>>
>> - Change "found" to "should be" in the error messages
>> - Merge remote-tracking branch
> There is some old awt/2d coding where warnings occur when running with ubsan
> enabled binaries.
> However at most of these locations the coding should work (at least on our
> supported platform set) so the warnings can be disabled at least for now.
>
> The change adds a macro ATTRIBUTE_NO_UBS
On Tue, 1 Oct 2024 15:49:22 GMT, Maurizio Cimadamore
wrote:
>> test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantAsType.java
>> line 103:
>>
>>> 101: }
>>> 102:
>>> 103: @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>
>> I think the intent was to block inlining
> The fix for JDK-8331865 introduced an accidental performance regression.
> The main issue is that now *all* memory segment var handles go through some
> round of adaptation.
> Adapting a var handle results in a so called *indirect* var handle.
> When an indirect var handle is called through a *v
On Tue, 1 Oct 2024 14:10:04 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update copyright
>
> test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantAsType.java
> line 103:
>
On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests to deprecate the unused class
>> `java.util.zip.ZipError` for removal.
>>
>> The class has been unsed by OpenJDK since the ZIP API was rewritten from
>> native to Java in JDK 9.
>>
>> I opted to n
On Mon, 30 Sep 2024 23:13:54 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/FileInputStream.java line 118:
>>
>>> 116: /**
>>> 117: * Creates a {@code FileInputStream} to read from an existing file
>>> 118: * named by the {@code File} object {@code file}.
>>
>
On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates code and tests in `java.base` to
>> consistently use `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH`
>> when referring to the JVM's maximum array size implementation limit.
>> Currentl
On Tue, 1 Oct 2024 05:52:23 GMT, Eirik Bjørsnøs wrote:
>> As this stands (modulo my other comments) this change is mostly OK. Using
>> the SOFT_MAX value within java.base is fine. Using SOFT_MAX within
>> java.base-related tests is a little suspicious, because it requires the
>> addition of di
The fix for JDK-8331865 introduced an accidental performance regression.
The main issue is that now *all* memory segment var handles go through some
round of adaptation.
Adapting a var handle results in a so called *indirect* var handle.
When an indirect var handle is called through a *var handle
On Tue, 1 Oct 2024 14:21:19 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen wrote:
>> This PR support a -k, --keep options like tar that allows jar to avoid
>> override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Address review feedbacks
> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> The implementation of java.lang.invoke uses SoftReferences so that unused
> MethodHandles, LambdaForms, etc, can be garbage collected.
>
> However, if we want to store j
> This implementation of MutableBigInteger.leftShift(int) optimizes the current
> version, avoiding unnecessary copy of the MutableBigInteger's value content
> and performing the primitive shifting only in the original portion of the
> value array rather than in the value yet extended with trail
On Tue, 1 Oct 2024 10:18:15 GMT, Maurizio Cimadamore
wrote:
>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some
>> round of adaptation.
>> Adapting a var handle results in a so called *indirec
On Sat, 28 Sep 2024 07:30:18 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the
On Tue, 1 Oct 2024 10:08:54 GMT, Maurizio Cimadamore
wrote:
> The fix for JDK-8331865 introduced an accidental performance regression.
> The main issue is that now *all* memory segment var handles go through some
> round of adaptation.
> Adapting a var handle results in a so called *indirect* v
On Mon, 30 Sep 2024 15:21:31 GMT, Henry Jen wrote:
> Some other comments also related to copied code, I can do a round of clean up.
Thank you Henry, that sounds fine to me.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1782590139
This fixes a format string issue.
In the error report it was reported : 'The compiler should be able to catch
this if JLI_ReportErrorMessageSys was declared with something like
__attribute__ ((format (printf, 1, 2))).'
Should we maybe adjust JLI_ReportErrorMessageSys , JLI_ReportErrorMessage a
On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken wrote:
> This fixes a format string issue.
>
> In the error report it was reported : 'The compiler should be able to catch
> this if JLI_ReportErrorMessageSys was declared with something like
> __attribute__ ((format (printf, 1, 2))).'
> Should
On Sun, 29 Sep 2024 22:16:47 GMT, David Holmes wrote:
> `jni_md.h` is shipped as part of every JDK distribution - this change does
> NOT belong in that file.
Hi David, should I introduce a separate ub.hpp (similar to what we have in
Hotspot) ?
-
PR Comment: https://git.openjdk.o
On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates code and tests in `java.base` to
>> consistently use `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH`
>> when referring to the JVM's maximum array size implementation limit.
>> Currentl
On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken wrote:
> This fixes a format string issue.
>
> In the error report it was reported : 'The compiler should be able to catch
> this if JLI_ReportErrorMessageSys was declared with something like
> __attribute__ ((format (printf, 1, 2))).'
> Should
On Tue, 1 Oct 2024 09:02:36 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Small correction to ensure n > leadingZeros && nBits > leadingZeros
>
> test/jdk/java/math/BigInteger/MutableBig
On Mon, 30 Sep 2024 12:03:14 GMT, Severin Gehwolf wrote:
>> Please review this fix for cgroups-based metrics reporting in the
>> `jdk.internal.platform` package. This fix is supposed to address wrong
>> reporting of certain limits if the limits aren't set at the leaf nodes.
>>
>> For example,
On Mon, 30 Sep 2024 22:39:09 GMT, Sandhya Viswanathan
wrote:
>> I think you have to do the masking before conversion -
>> `vec.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle()` is not the
>> same as `vec.toShuffle()` for all inputs.
>>
>>
>> jshell> IntVector indexes = IntVector.fr
On Tue, 1 Oct 2024 13:15:51 GMT, Matthias Baesken wrote:
>> This fixes a format string issue.
>>
>> In the error report it was reported : 'The compiler should be able to catch
>> this if JLI_ReportErrorMessageSys was declared with something like
>> __attribute__ ((format (printf, 1, 2))).'
>>
On Mon, 30 Sep 2024 23:16:56 GMT, Brian Burkhalter wrote:
> > Do you think, as part of this PR, we should also revisit some of the
> > javadoc in the `java.io.FileOutputStream` class which too has several
> > mentions of "connection"?
>
> Are you thinking of this sentence
>
> `A new FileDescr
On Tue, 1 Oct 2024 08:20:43 GMT, Matthias Baesken wrote:
> Hi David, should I introduce a separate ub.hpp (similar to what we have in
> Hotspot) ?
As previously discussed above a separate header would be best, though I'm not
sure where it would be placed if you are using this across code in di
On Tue, 1 Oct 2024 12:40:57 GMT, Matthias Baesken wrote:
>> src/java.base/macosx/native/libjli/java_md_macosx.m line 315:
>>
>>> 313: rc = pthread_create(&main_thr, NULL, &apple_main, &args);
>>> 314: if (rc != 0) {
>>> 315: JLI_ReportErrorMessageSys("Could not create main thread
On Tue, 1 Oct 2024 06:28:02 GMT, David Holmes wrote:
>> In this case there is no classic release/acquire. Instead, we rely on other
>> properties: The `vmentry` field is loaded in
>> `MethodHandles::jump_to_lambda_form`, using a plain load. I believe a
>> load-acquire is not needed here becaus
On Tue, 1 Oct 2024 10:36:01 GMT, Claes Redestad wrote:
> LGTM
>
> In the micro perhaps the `unsafe_loop` variant is superfluous for this
> special case test? At least it's distinct from the test in
> `LoopOverNonConstant` by summing longs rather than ints.
Yeah - that is a bit redundant - how
On Tue, 1 Oct 2024 13:15:51 GMT, Matthias Baesken wrote:
>> This fixes a format string issue.
>>
>> In the error report it was reported : 'The compiler should be able to catch
>> this if JLI_ReportErrorMessageSys was declared with something like
>> __attribute__ ((format (printf, 1, 2))).'
>>
On Mon, 30 Sep 2024 23:36:35 GMT, Chen Liang wrote:
> Perform validation of local variable slots, multinewarray dimension, iinc
> value and specify these validations are performed. Specify these exception
> behaviors for sipush and bipush as well.
>
> This validation avoids using invalid value
On Tue, 1 Oct 2024 10:18:15 GMT, Maurizio Cimadamore
wrote:
>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some
>> round of adaptation.
>> Adapting a var handle results in a so called *indirec
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> for following new two vector permutation APIs.
>
>
> Declaration:-
> Vector.selectFrom(Vector v1, Vector v2)
>
>
> Semantics:-
> Using index values stored in the lanes of "this" vector, assembl
On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken wrote:
> This fixes a format string issue.
>
> In the error report it was reported : 'The compiler should be able to catch
> this if JLI_ReportErrorMessageSys was declared with something like
> __attribute__ ((format (printf, 1, 2))).'
> Should
> This fixes a format string issue.
>
> In the error report it was reported : 'The compiler should be able to catch
> this if JLI_ReportErrorMessageSys was declared with something like
> __attribute__ ((format (printf, 1, 2))).'
> Should we maybe adjust JLI_ReportErrorMessageSys , JLI_ReportErr
> This implementation of MutableBigInteger.leftShift(int) optimizes the current
> version, avoiding unnecessary copy of the MutableBigInteger's value content
> and performing the primitive shifting only in the original portion of the
> value array rather than in the value yet extended with trail
1 - 100 of 105 matches
Mail list logo
