Re: RFR: 8338023: Support two vector selectFrom API [v13]

On Tue, 1 Oct 2024 18:03:06 GMT, Sandhya Viswanathan wrote: >>> This could instead be: src1.rearrange(this.lanewise(VectorOperators.AND, 2 >>> * VLENGTH - 1).toShuffle(), src2); Or even simplified to: >>> src1.rearrange(this.toShuffle(), src2); >> >> Yes, this may save additional allocation p

Re: RFR: 8338023: Support two vector selectFrom API [v14]

On Tue, 1 Oct 2024 18:10:10 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comments resolutions. > > src/hotspot/share/opto/vectorIntrinsics.cpp line 2797: > >> 2795: >> 2796:

Re: RFR: 8338023: Support two vector selectFrom API [v15]

> 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

Withdrawn: 8332744: [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version

On Fri, 24 May 2024 15:32:09 GMT, Liam Miller-Cushon wrote: > This change fixes a bug preventing javac from emitting > 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a > non-default value. The diagnostics are currently emitted for values of > `--release`, and for the defau

Re: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]

On Thu, 26 Sep 2024 16:17:49 GMT, Chris Plummer wrote: >> Dhamoder Nalla has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fix missing code > > I don't have a suggestion for maintaining compatibility other than not making > the change. T

Re: RFR: 8321413: IllegalArgumentException: Code length outside the allowed range while creating a jlink image [v3]

On Fri, 27 Sep 2024 18:03:14 GMT, Henry Jen wrote: >> This PR split out large array/set construction into separate factory methods >> to avoid oversized method trying to construct several of those. >> >> In order to do that, we will need to generate those help methods on demand >> in the class

Re: RFR: 8340229: Improve opening sentence of FileInputStream constructor specification [v3]

On Wed, 2 Oct 2024 15:23:52 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

Re: RFR: 8341006: Optimize StackMapGenerator detect frames [v2]

On Fri, 27 Sep 2024 01:34:18 GMT, Shaojin Wen wrote: >> 1. Construct Frames directly without BitSet >> 2. Use Frame[] instead of ArrayList >> 3. Use EMPTY_FRAME_ARRAY for initialization. No need to allocate objects >> when there is no frame. > > Shaojin Wen has updated the pull request increment

Re: RFR: 8341445: DecimalFormatSymbols can throw NPE for equals()

On Wed, 2 Oct 2024 23:16:32 GMT, Justin Lu wrote: > Please review this PR which improves the safety of equality checking for > DecimalFormatSymbols. > > DecimalFormatSymbols via its setters, allows certain instance variables to be > set as null. (Note that some variables are allowed to be null

Re: RFR: 8341402: BigDecimal's square root optimization [v2]

On Thu, 3 Oct 2024 00:05:17 GMT, fabioromano1 wrote: >> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed >> up `BigDecimal.sqrt()` implementation. Here is how I made it. >> >> The main steps of the algorithm are as follows: >> first argument reduce the value to an in

Re: RFR: 8341402: BigDecimal's square root optimization [v2]

> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed > up `BigDecimal.sqrt()` implementation. Here is how I made it. > > The main steps of the algorithm are as follows: > first argument reduce the value to an integer using the following relations: > > x = y * 10 ^ exp >

Re: RFR: 8339538: Wrong timeout computations in DnsClient [v8]

On Wed, 2 Oct 2024 13:25:54 GMT, Aleksei Efimov wrote: > > I think that if there is a PortUnreachable thrown, during DnsClient.query > > processing from the doUdpQuery, then the timeout may expire early ... if > > I've interpreted the outer loop processing correctly > > The `DnsClient.query` m

RFR: 8341445: DecimalFormatSymbols can throw NPE for equals()

Please review this PR which improves the safety of equality checking for DecimalFormatSymbols. DecimalFormatSymbols via its setters, allows certain instance variables to be set as null. (Note that some variables are allowed to be null, and others are not.) However, non null safe comparisons are

Re: RFR: 8341127: Extra call to MethodHandle::asType from memory segment var handles fails to inline [v5]

On Wed, 2 Oct 2024 14:02:19 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

Re: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and MethodTypeForm when storing heap objects into AOT cache [v7]

On Wed, 2 Oct 2024 01:06:20 GMT, Ioi Lam wrote: >> 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

Re: RFR: 8341415: Optimize RawBytecodeHelper::next

On Wed, 2 Oct 2024 07:53:44 GMT, Shaojin Wen wrote: > A small optimization to the RawBytecodeHelper::next method > * Remove `len <= 0` once > * merge store opcode and isWide Marked as reviewed by liach (Reviewer). This patch is neutral for startup benchmark. Good if it improves the repeated JM

Withdrawn: 8337838: Remove unused methods from ChronoLocalDateImpl

On Fri, 19 Jul 2024 09:52:50 GMT, Andrey Turbanov wrote: > A few methods in `java.time.chrono.ChronoLocalDateImpl` are unused and could > be removed: > 1. plusWeeks(long) > 2. minusYears(long) > 3. minusMonths(long) > 4. minusWeeks(long) > 5. minusDays(long) > > Tested `test/jdk/java/time` on L

Re: Illegal Seek when using File.newInputStream()

Hi Louis, I have a functional patch implemented. It adds available() to FileChannelImpl which then uses it if the SeekableByteChannel is a FileChannelImpl. The patch only had the UNIX changes for now; I’ve not investigated Windows enough to know what to do there. Does that sound reasonable?

Re: Illegal Seek when using File.newInputStream()

If I wanted to contribute a patch, can you suggest what you think would be the best path forward? I've listed some options but I'm sure there are more: 1.It seems like amending the underlying issue in the native code underlying FileDispatcherImpl.seek() so that it returns a value when asked f

Re: RFR: 8341443: [macos] AppContentTest and SigningOptionsTest failed due to "codesign" does not fails with "--app-content" on macOS 15

On Wed, 2 Oct 2024 20:32:57 GMT, Alexander Matveev wrote: > - `AppContentTest` and `SigningOptionsTest` failed on macOS 15 due to > `codesign` no longer fails if additional content is added to app image. > - `SigningOptionsTest` fixed by failing `codesign` due to missing identity, > since we on

RFR: 8341443: [macos] AppContentTest and SigningOptionsTest failed due to "codesign" does not fails with "--app-content" on macOS 15

- `AppContentTest` and `SigningOptionsTest` failed on macOS 15 due to `codesign` no longer fails if additional content is added to app image. - `SigningOptionsTest` fixed by failing `codesign` due to missing identity, since we only need to check that warning message is displayed when codesign fa

Re: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]

On Tue, 1 Oct 2024 13:45:56 GMT, Matthias Baesken wrote: >> 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

Re: RFR: 8341415: Optimize RawBytecodeHelper::next

On Wed, 2 Oct 2024 19:59:07 GMT, ExE Boss wrote: >> The checkSpecialInstruction has already added the 'len <= 0' process, so >> there is no need to check 'len <= '0' again. > > `checkSpecialInstruction` will return `-1` in the following cases: > * `code == WIDE` and `bci + 1 >= end` > * `code ==

Re: RFR: 8339260: Move rarely used constants out of ClassFile [v9]

On Wed, 2 Oct 2024 19:16:08 GMT, Luca Kellermann wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> AbstractPoolEntry is broken too > > src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 482: > >

Re: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files [v4]

On Tue, 10 Sep 2024 05:46:46 GMT, Jaikiran Pai wrote: >> I pushed the review suggestions. There were two GitHub Actions failures on >> `macos-aarch64`, but they look to be occurrences of this existing bug: >> https://bugs.openjdk.org/browse/JDK-8247940. > > Hello @fitzsim, I plan to take a loo

Re: RFR: 8339260: Move rarely used constants out of ClassFile [v9]

On Tue, 24 Sep 2024 17:23:41 GMT, Chen Liang wrote: >> Many constants are cluttered in `ClassFile`. However, only a few of them are >> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` >> constants. All other constants are specific and should live in more local >> loca

Re: RFR: 8341415: Optimize RawBytecodeHelper::next

On Wed, 2 Oct 2024 13:29:22 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java >> line 449: >> >>> 447: } >>> 448: >>> 449: if ((nextBci += len) > end) { >> >> This change makes it that `nextBci` will no longer monotonical

Re: RFR: 8337753: Target class of upcall stub may be unloaded [v6]

On Thu, 19 Sep 2024 12:20:13 GMT, Jorn Vernee wrote: >> As discussed in the JBS issue: >> >> FFM upcall stubs embed a `Method*` of the target method in the stub. This >> `Method*` is read from the `LambdaForm::vmentry` field associated with the >> target method handle at the time when the upca

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 18:16:06 GMT, Raffaello Giulietti wrote: > Without experimenting a bit, it's hard to tell. Anyway, I believe the current > implementation of `stripZerosToMatchScale()` is O(n^2) rather than > exponential, because each single division by 10 is linear. > > But let's focus on

Re: RFR: 8337753: Target class of upcall stub may be unloaded [v6]

On Thu, 19 Sep 2024 12:20:13 GMT, Jorn Vernee wrote: >> As discussed in the JBS issue: >> >> FFM upcall stubs embed a `Method*` of the target method in the stub. This >> `Method*` is read from the `LambdaForm::vmentry` field associated with the >> target method handle at the time when the upca

Re: Illegal Seek when using File.newInputStream()

The InputStream created over the FileChannel assumes that the FileChannel is connected to a regular file, which isn't the case with this character special file and several other pseudo devices. As you've found, many of the methods defined by FileChannel doesn't make sense with these devices.

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 18:06:57 GMT, fabioromano1 wrote: >> After looking at the code more closely, these are _not_ the reasons for the >> long running times of my example above. >> Neither the computation of the large power of 10, nor the multiplication, >> nor the `BigInteger` square root are slo

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 17:37:03 GMT, Raffaello Giulietti wrote: >> @rgiulietti The only solution I can think of to avoid this is to reimplement >> Zimmerman's square root algorithm in the class `BigDecimal`, using the radix >> 10 representation of the number's magnitude. > > After looking at the c

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 16:32:47 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/BigDecimal.java line 2213: >> >>> 2211: >>> 2212: BigDecimal working = new BigDecimal(this.intVal, >>> this.intCompact, (int) workingScale, this.precision); >>> 2213: B

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 13:44:42 GMT, Raffaello Giulietti wrote: > Curiously, this one runs in a fraction of a second on the current > implementation, but not on the proposed one: > `BigDecimal.valueOf(100).sqrt(new MathContext(1_000_000, > RoundingMode.HALF_EVEN)).shortValue()` @rgiulietti This

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 16:15:29 GMT, fabioromano1 wrote: >> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed >> up `BigDecimal.sqrt()` implementation. Here is how I made it. >> >> The main steps of the algorithm are as follows: >> first argument reduce the value to an in

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 10:31:09 GMT, fabioromano1 wrote: > After changing `BigInteger.sqrt()` algorithm, this can be also used to speed > up `BigDecimal.sqrt()` implementation. Here is how I made it. > > The main steps of the algorithm are as follows: > first argument reduce the value to an integer

Integrated: 8328313: Archived module graph should allow identical --module-path to be specified during dump time and run time

On Tue, 17 Sep 2024 23:44:40 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, the

Re: RFR: 8328313: Archived module graph should allow identical --module-path to be specified during dump time and run time [v10]

On Wed, 2 Oct 2024 05:50:14 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

Integrated: 8339850: Restore the interrupt status in FileSystemPreferences.lockFile()

On Tue, 10 Sep 2024 16:37:11 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 > restores th

Re: RFR: 8340229: Improve opening sentence of FileInputStream constructor specification [v3]

On Wed, 2 Oct 2024 15:23:52 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

Illegal Seek when using File.newInputStream()

Hello, There's a long standing bug when using Files.newInputStream() with unix non-regular files. (/dev/stdin , /dev/random/ etc). It was reported in JDK-8233451 but it doesn't seem like there's been much movement on it. It's causing repeated prob

Re: RFR: 8340229: Improve opening sentence of FileInputStream constructor specification [v2]

On Wed, 2 Oct 2024 06:45:51 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8340229: Revert FIS(fdObj) change > > src/java.base/share/classes/java/io/FileInputStream.java line 118: > >> 116:

Re: RFR: 8340229: Improve opening sentence of FileInputStream constructor specification [v3]

> 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: Correct typo in FIS - Changes: -

Re: RFR: 8339850: Restore the interrupt status in FileSystemPreferences.lockFile() [v3]

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

Re: RFR: 8339850: Restore the interrupt status in FileSystemPreferences.lockFile() [v3]

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

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 10:31:09 GMT, fabioromano1 wrote: > After changing `BigInteger.sqrt()` algorithm, this can be also used to speed > up `BigDecimal.sqrt()` implementation. Here is how I made it. > > The main steps of the algorithm are as follows: > first argument reduce the value to an integer

Re: RFR: 8331051: Add an `@since` checker test for `java.base` module [v16]

> This checker checks the values of the `@since` tag found in the documentation > comment for an element against the release in which the element first > appeared. > > Real since value of an API element is computed as the oldest release in which > the given API element was introduced. That is:

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 13:49:29 GMT, Raffaello Giulietti wrote: >> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed >> up `BigDecimal.sqrt()` implementation. Here is how I made it. >> >> The main steps of the algorithm are as follows: >> first argument reduce the value

Re: RFR: 8341127: Extra call to MethodHandle::asType from memory segment var handles fails to inline [v5]

> 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

Re: RFR: 8341127: Extra call to MethodHandle::asType from memory segment var handles fails to inline [v4]

On Tue, 1 Oct 2024 22:51:01 GMT, Vladimir Ivanov wrote: > I don't have a clear understanding how `VarHandleGuards` is used, but I > assume that `MethodHandle::asType` calls there are no-ops in scenarios you > care about. A var handle guard is a piece of code that detects var handle call of a c

Re: RFR: 8341415: Optimize RawBytecodeHelper::next

On Wed, 2 Oct 2024 13:28:24 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java >> line 350: >> >>> 348: */ >>> 349: public boolean isWide() { >>> 350: return (opcode & (WIDE << 8)) != 0; >> >> Suggestion: >> >> re

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 10:31:09 GMT, fabioromano1 wrote: > After changing `BigInteger.sqrt()` algorithm, this can be also used to speed > up `BigDecimal.sqrt()` implementation. Here is how I made it. > > The main steps of the algorithm are as follows: > first argument reduce the value to an integer

Re: RFR: 8341415: Optimize RawBytecodeHelper::next

On Wed, 2 Oct 2024 11:09:52 GMT, ExE Boss wrote: >> A small optimization to the RawBytecodeHelper::next method >> * Remove `len <= 0` once >> * merge store opcode and isWide > > src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java > line 350: > >> 348: */ >> 349:

Re: RFR: 8341415: Optimize RawBytecodeHelper::next

On Wed, 2 Oct 2024 07:53:44 GMT, Shaojin Wen wrote: > A small optimization to the RawBytecodeHelper::next method > * Remove `len <= 0` once > * merge store opcode and isWide src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 350: > 348: */ > 349: publi

RFR: 8341415: Optimize RawBytecodeHelper::next

A small optimization to the RawBytecodeHelper::next method * Remove `len <= 0` once * merge store opcode and isWide - Commit messages: - merge store opcode & isWide - optimize RawBytecodeHelper::next Changes: https://git.openjdk.org/jdk/pull/21300/files Webrev: https://webrevs.op

Re: RFR: 8341402: BigDecimal's square root optimization

On Wed, 2 Oct 2024 10:31:09 GMT, fabioromano1 wrote: > After changing `BigInteger.sqrt()` algorithm, this can be also used to speed > up `BigDecimal.sqrt()` implementation. Here is how I made it. > > The main steps of the algorithm are as follows: > first argument reduce the value to an integer

Re: RFR: 8339538: Wrong timeout computations in DnsClient [v9]

On Wed, 2 Oct 2024 13:35:00 GMT, Aleksei Efimov wrote: >> This PR proposes the following changes to address wrong timeout computations >> in the `com.sun.jndi.dns.DnsClient`: >> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) >> clock. The existing `Timeout` test ha

Re: RFR: 8339538: Wrong timeout computations in DnsClient [v9]

> This PR proposes the following changes to address wrong timeout computations > in the `com.sun.jndi.dns.DnsClient`: > - The `DnsClient` has been updated to use a monotonic high-resolution (nano) > clock. The existing `Timeout` test has also been updated to use the nano > clock to measure obser

Re: RFR: 8339538: Wrong timeout computations in DnsClient [v8]

On Mon, 30 Sep 2024 13:38:48 GMT, Daniel Fuchs wrote: >> Aleksei Efimov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Track unfulfilled timeouts during UDP queries. >> Update exceptions handling. >> Update TCP client to use nano ti

Re: RFR: 8339538: Wrong timeout computations in DnsClient [v8]

On Mon, 30 Sep 2024 20:30:57 GMT, Mark Sheppard wrote: > I think that if there is a PortUnreachable thrown, during DnsClient.query > processing from the doUdpQuery, then the timeout may expire early ... if I've > interpreted the outer loop processing correctly The `DnsClient.query` marks serve

RFR: 8341402: BigDecimal's square root optimization

After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it. The main steps of the algorithm are as follows: first argument reduce the value to an integer using the following relations: x = y * 10 ^ exp sqrt(x) = sqrt(

Re: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]

On Wed, 2 Oct 2024 09:38:41 GMT, David Holmes wrote: > > So maybe src/java.base/unix/native/libjava > > That is header files for libjava. > > This is why I said it would be hard to find a shared location where this can > be used across different modules - because there presently isn't one. In

Re: RFR: 8329597: C2: Intrinsify Reference.clear [v6]

On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev wrote: >> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native >> method for `Reference.clear`. The original patch skipped intrinsification of >> this method, because we thought `Reference.clear` is not on a performance

Integrated: 8336274: MutableBigInteger.leftShift(int) optimization

On Wed, 3 Jul 2024 14:17:37 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 > value

Re: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v17]

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

Re: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]

On Tue, 1 Oct 2024 13:45:56 GMT, Matthias Baesken wrote: >> 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

Re: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v17]

On Tue, 1 Oct 2024 20:43:24 GMT, fabioromano1 wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Code simplification > > `/integrate` @fabioromano1 Seems like your integration was not successful. Retry without any fo

Integrated: 8341135: Incorrect format string after JDK-8339475

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

Re: RFR: 8340801: Disable ubsan checks in some awt/2d coding

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

Re: RFR: 8328313: Archived module graph should allow identical --module-path to be specified during dump time and run time [v10]

On Wed, 2 Oct 2024 05:50:14 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