On Mon, 28 Jul 2025 19:06:13 GMT, Chen Liang wrote:
>> I have updated this patch to avoid a redundant `runtimeSetup` annotation -
>> we have agreed that the requirement for setup is a side effect of
>> initialization, and such methods in AOTCI classes must be automatically
>> recognized. This
Chen,
Thanks for the clarification. The StringCoding methods are a bit light on
documentation, but presumably because of the package scope.
The specific method I am proposing a change to is a private method in
String.
Thanks,
Brett
On Mon, Jul 28, 2025 at 5:26 PM Chen Liang wrote:
> Hi Brett
Hi Brett, you are right.
In the scenario Roger described, the current code would already be unsafe
because the hasNegatives check and the clone copy are two distinct reads to
each array element, between which a mutation can happen.
Roger is mainly concerned because byte[] with LATIN1 or UTF16 d
On Mon, 28 Jul 2025 20:14:15 GMT, Coleen Phillimore wrote:
> This change removes the intrinsic for getClassAccessFlagsRaw for reflection
> and initializes an rawAccessFlags field in java.lang.Class instead, that Java
> code can non-natively access.
> Tested with tier1-4.
src/java.base/share/cl
Roger,
For a String, the byte[] val is immutable, right?
And even the current behavior of checking for negatives and then cloning
would not be safe in the face of a concurrent modification, right?
Is there something else going on here which I am missing?
Thanks,
Brett
On Mon, Jul 28, 2025 at 3:1
On Thu, 24 Jul 2025 06:07:31 GMT, John R Rose wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 24 commits:
>>
>> - Merge branch 'master' of https://github.com/openjdk/jdk into
>> exp/cds-mh-anno
>> - Merge b
This change removes the intrinsic for getClassAccessFlagsRaw for reflection and
initializes an rawAccessFlags field in java.lang.Class instead, that Java code
can non-natively access.
Tested with tier1-4.
-
Commit messages:
- The only caller for getRawClassAccessFlags in Class.java
Hi Brett,
Extra care is needed if the input array might be modified concurrently
with the method execution.
When control flow decisions are made based on array contents, the
integrity of the result depends on reading each byte of the array
exactly once.
Regards, Roger
On 7/27/25 4:45 PM,
Hi All,
For anyone interested in experimenting with the proposed java.util.json API
design, I've created a backport that works with JDK 21:
https://github.com/simbo1905/java.util.json.Java21
This is derived from the OpenJDK sandbox commit d22dc2ba (mid-July 2025). The
backport:
- Works with J
On Mon, 2 Jun 2025 11:54:10 GMT, Alice Pellegrini wrote:
> The implemented solution modifies the `OutputBuffer` implementation instead
> of the `OutputAnalyzer` implementation.
> This is because the **OutputBuffer implementation which handles processes**
> (LazyOutputBuffer) starts a thread in
On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini wrote:
>> The implemented solution modifies the `OutputBuffer` implementation instead
>> of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes**
>> (LazyOutputBuffer) starts a thread
On Mon, 28 Jul 2025 19:06:13 GMT, Chen Liang wrote:
>> I have updated this patch to avoid a redundant `runtimeSetup` annotation -
>> we have agreed that the requirement for setup is a side effect of
>> initialization, and such methods in AOTCI classes must be automatically
>> recognized. This
> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we
> have agreed that the requirement for setup is a side effect of
> initialization, and such methods in AOTCI classes must be automatically
> recognized. This latest revision implements that model.
>
> I intentionall
On Thu, 17 Jul 2025 18:46:06 GMT, Mohamed Issa wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are
>> included to check the performance of specific input value ranges to help
>> prevent regression
On Mon, 28 Jul 2025 17:13:48 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1993:
>>
>>> 1991: * non-significant bits), and the shift is performed in
>>> order to lose
>>> 1992: * the smallest number of bits in the signifi
On Mon, 28 Jul 2025 17:03:48 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Zimmermann suggestion
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 1993:
>
>> 1991:
> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString`
> to avoid byte[] allocation in the String constructor.
>
> Fall back to the old code in the case of malformed input to get replacement
> characters as per Javadoc API specification. The existing tests in
> `TestStri
On Mon, 28 Jul 2025 01:15:17 GMT, simon wrote:
>> Philippe Marschall has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix copyright year
>
> src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 33:
>
>> 31: import jdk
On Mon, 28 Jul 2025 14:03:16 GMT, fabioromano1 wrote:
>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Zimmermann suggestion
src/java.base/shar
On Fri, 25 Jul 2025 21:25:36 GMT, Alexander Matveev
wrote:
> - Wrong package was generated for SQE. Fixed by generating correct package
> for SQE.
> - Issue with appOutput.txt is not created will be fixed with
> https://bugs.openjdk.org/browse/JDK-8358723.
This pull request has now been integ
On Mon, 28 Jul 2025 16:19:07 GMT, Alexey Semenyuk wrote:
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties
>> line 89:
>>
>>> 87: MSG_BundlerConfigExceptionNoAdvice=Bundler {0} aufgrund eines
>>> Konfigurationsproblems übersprungen: {1}
>>> 88: MSG_B
On Fri, 25 Jul 2025 16:23:22 GMT, Justin Lu wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK since the previous L10n drop.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties
> line 89:
On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung wrote:
> This issue is responsible for updating the translations of all the
> localize(able) resources in the JDK since the previous L10n drop.
Marked as reviewed by asemenyuk (Reviewer).
jpackage changes look good
-
PR Review: https
On Mon, 28 Jul 2025 14:04:32 GMT, Shaojin Wen wrote:
>> I agree that we can expect arrays to be laid out as a contiguous chunk of
>> memory with the intuitively expected element size.
>> _But..._ AFAIK this is not specified anywhere in the JVMS, although it is
>> true that it is tacitly assumed
On Sun, 27 Jul 2025 10:23:03 GMT, Tatsunori Uchino wrote:
> The addition to CharSequence will require static analysis to check for
> conflicts with implementation. It will also likely impact the CharBuffer spec.
Looking at the original JSR 204 issue:
https://bugs.openjdk.org/browse/JDK-4985217
On Mon, 28 Jul 2025 12:46:22 GMT, Raffaello Giulietti
wrote:
>> String uses `<< coder` in many places. I think the following way of writing
>> is also good:
>>
>> Unsafe.getUnsafe().copyMemory(
>> ca,
>> Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << Stri
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Zimmermann suggestion
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24898/files
- ne
> This set of updates reduces contention-based performance loss under heavy
> over-subscription, while also improving perfomance more generally.
Doug Lea 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
On Tue, 8 Jul 2025 05:13:49 GMT, Jaikiran Pai wrote:
> Hello Matthew, In recent times we have been adding more of these
> configuration debugging into the -XshowSettings option. I'm unusure to what
> extent this option should be advertized or used for gathering such details of
> the runtime. W
On Sun, 27 Jul 2025 08:26:59 GMT, Thomas Zimmermann wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> A zero root's shift can't be excluded
>
> src/java.base/share/classes/java/math/BigInteger.java line 2773:
>
>> 2
On Thu, 24 Jul 2025 14:38:13 GMT, Roger Riggs wrote:
>> I recall runtime requires UTF16 byte array and char array have exactly the
>> same layout - would be nice if we keep this in the design notes for the
>> string implementation classes, such as on the class header.
>>
>> (Useful notes could
On Sun, 27 Jul 2025 08:26:59 GMT, Thomas Zimmermann wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> A zero root's shift can't be excluded
>
> src/java.base/share/classes/java/math/BigInteger.java line 2773:
>
>> 2
On Mon, 28 Jul 2025 01:11:26 GMT, Shaojin Wen wrote:
>> I prefer to calculate an ARRAY_CHAR_SHIFT in the constant like ShortVector
>> does, like this
>>
>> static final int ARRAY_CHAR_SHIFT
>>= 31 -
>> Integer.numberOfLeadingZeros(Unsafe.ARRAY_CHAR_INDEX_SCALE);
>>
>>
On Mon, 28 Jul 2025 09:16:15 GMT, Alan Bateman wrote:
> I think we should mull over the addition of CharSequence::codePointCount. On
> the surface it looks like it fits but we can't rush it (CharSequence is
> widely implemented and additions to this interface have a history of
> disruption in
On Sun, 27 Jul 2025 08:26:59 GMT, Thomas Zimmermann wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> A zero root's shift can't be excluded
>
> src/java.base/share/classes/java/math/BigInteger.java line 2773:
>
>> 2
On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici wrote:
> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid
> characters, but throw `CharacterCodingException` on encounter. This behavior
> cannot easily be derived from the method footprints, has been a source of
> co
On Tue, 22 Jul 2025 16:03:59 GMT, Alan Bateman wrote:
> There are several places where "IAE" is mentioned but the methods are changed
> to throw CCE.
@AlanBateman, thanks for the tip. Pushed 10cb72cf17b, which improves Javadoc in
such places. While doing so, it also
* Ensures that `String` Ja
On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici wrote:
> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid
> characters, but throw `CharacterCodingException` on encounter. This behavior
> cannot easily be derived from the method footprints, has been a source of
> co
On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici wrote:
> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid
> characters, but throw `CharacterCodingException` on encounter. This behavior
> cannot easily be derived from the method footprints, has been a source of
> co
`NoRepl`-suffixed `String` methods denote methods that do not replace invalid
characters, but throw `CharacterCodingException` on encounter. This behavior
cannot easily be derived from the method footprints, has been a source of
confusion for maintainers, and is not uniformly adopted, e.g.,
`ne
On Mon, 21 Jul 2025 14:00:37 GMT, Volkan Yazici wrote:
> Would you mind elaborating on the rationale behind this preference, please?
If you look at the history of `newStringNoRepl`, you will find it's originally
added for JDK-8201276 in ca487166f4d18c162e8d8e4b2660d5d0381c5438. Since then,
`ne
On Mon, 21 Jul 2025 13:01:30 GMT, Chen Liang wrote:
>> `NoRepl`-suffixed `String` methods denote methods that do not replace
>> invalid characters, but throw `CharacterCodingException` on encounter. This
>> behavior cannot easily be derived from the method footprints, has been a
>> source of c
On Fri, 25 Jul 2025 07:40:46 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Sun, 27 Jul 2025 23:05:25 GMT, Tatsunori Uchino wrote:
> > Right now your PR is proposing to add a default method named codePointCount
> > to CharSequence.
>
> If it should be excluded for this time, I will push an additional commit to
> _remove_ it from the content in this PR.
I think we
> Hi all,
>
> please review this change that implements (currently Draft) JEP: G1:
> Improve Application Throughput with a More Efficient Write-Barrier.
>
> The reason for posting this early is that this is a large change, and the JEP
> process is already taking very long with no end in sight
45 matches
Mail list logo
