In the JDK code, there are some places that may cause Unsafe offset overflow.
The probability of occurrence is low, but if it occurs, it will cause JVM crash.
-
Commit messages:
- fix unsafe address overflow
Changes: https://git.openjdk.org/jdk/pull/22027/files
Webrev: https://we
On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Tue, 12 Nov 2024 05:42:46 GMT, Joe Darcy wrote:
>> Port of Float16 from java.lang in the lworld+fp16 branch to
>> jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brough
On Mon, 11 Nov 2024 14:03:54 GMT, Raffaello Giulietti
wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to review feedback.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line
> 4
> Port of Float16 from java.lang in the lworld+fp16 branch to
> jdk.incubabor.vector.
Joe Darcy 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 21 addi
On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes have been split into the
> following initial 4 commits:
>
> - Change
On Tue, 12 Nov 2024 01:25:16 GMT, Shaojin Wen wrote:
> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
> offset overflow issue has been fixed.
>
> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
> reduce duplication
>
> HexDigits and OctalDi
This PR is a resubmission after PR #21593 was rolled back, and the unsafe
offset overflow issue has been fixed.
Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
reduce duplication
HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
Putting these two
Good to know, ty vm.
At the very least, I have this workaround. This will meet my needs for now.
I guess my final question would be -- is this type of problem better suited
to something besides parallel streams? Maybe an ExecutorService?
Really, all I am doing is taking a jumbo file, splitting i
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Wed, 30 Oct 2024 08:54:55 GMT, kabutz wrote:
> The ArrayBlockingQueue has had a readObject() method since Java 7, which
> checks invariants of the deserialized object. However, it does not have a
> writeObject() method. This means that the ArrayBlockingQueue could be
> modified whilst it is
On Wed, 30 Oct 2024 08:54:55 GMT, kabutz wrote:
> The ArrayBlockingQueue has had a readObject() method since Java 7, which
> checks invariants of the deserialized object. However, it does not have a
> writeObject() method. This means that the ArrayBlockingQueue could be
> modified whilst it is
On Thu, 24 Oct 2024 15:09:00 GMT, Viktor Klang wrote:
> Make final adjustments to drop PreviewFeature and updating the @ since
> markers.
This pull request has now been integrated.
Changeset: ef0dc251
Author:Viktor Klang
URL:
https://git.openjdk.org/jdk/commit/ef0dc2518e7636cc8a9ca
You're most welcome!
In a potential future where all intermediate operations are Gatherer-based, and
all terminal operations are Collector-based, it would just work as expected.
But with that said, I'm not sure it is practically achievable because some
operations might not have the same perform
On Wed, 6 Nov 2024 15:47:55 GMT, Alan Bateman wrote:
> Changes for [JEP draft: Structured Concurrency (Fourth
> Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical
> roadmap yet. The proposal is to re-preview the API with some changes,
> specifically:
>
> - A
> [Struc
On Mon, 11 Nov 2024 15:48:48 GMT, Severin Gehwolf wrote:
> So on cg v1 you start out and end with a `subsystem_path() == null` and on cg
> v2 you start out and end with a `subsystem_path() ==
> /../../../../../../test`. In both cases the memory limit of 400m won't be
> detected.
Only when doc
On Fri, 8 Nov 2024 21:01:57 GMT, Phil Race wrote:
>>> I'd not looked at this test before but when I do the thing I noticed is
>>> that createPrivateValue is no longer used. But I don't see a problem with
>>> keeping the rest of the test.
>>
>> @prrace Do I understand correctly that _“`createPr
On Wed, 6 Nov 2024 15:25:07 GMT, Jorn Vernee wrote:
> Maybe we should also check that padding layouts have natural alignment? The
> alignment of padding layouts can affect the alignment of the enclosing
> container.
This makes sense, but I wonder if that would require a change in the javadoc?
Thanks for the workaround. It's running beautifully.
Is there a future where this island concept is extended to the rest of
streams? Tbh, I don't fully understand it.
On Mon, Nov 11, 2024, 9:59 AM Viktor Klang wrote:
> Hi David,
>
> This is the effect of how parallel streams are implemented, wh
On Mon, 11 Nov 2024 14:50:57 GMT, Per Minborg wrote:
>> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
>> size of the segments varies.
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes
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
On Mon, 11 Nov 2024 15:16:15 GMT, Severin Gehwolf wrote:
> On cg v2, on the other hand, `set_subsystem_path()` will never set the path
> to a `null` value.
Exactly. That's why JDK-8322420 is not in effect and also
[JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) does not fix it on
J
> This addresses tendencies in previous update to increase fencing, scanning,
> and signalling that can increase contention, and slow down performance
> especially on ARM platforms. It also uses more ARM-friendly constructions to
> reduce overhead (leading to several changes that all of the same
On Tue, 22 Oct 2024 12:49:08 GMT, David M. Lloyd wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It wa
On Mon, 11 Nov 2024 16:01:08 GMT, Doug Lea wrote:
>> This addresses tendencies in previous update to increase fencing, scanning,
>> and signalling that can increase contention, and slow down performance
>> especially on ARM platforms. It also uses more ARM-friendly constructions to
>> reduce o
> This addresses tendencies in previous update to increase fencing, scanning,
> and signalling that can increase contention, and slow down performance
> especially on ARM platforms. It also uses more ARM-friendly constructions to
> reduce overhead (leading to several changes that all of the same
> This addresses tendencies in previous update to increase fencing, scanning,
> and signalling that can increase contention, and slow down performance
> especially on ARM platforms. It also uses more ARM-friendly constructions to
> reduce overhead (leading to several changes that all of the same
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Mon, 11 Nov 2024 10:20:02 GMT, Severin Gehwolf wrote:
> > In the above script, a containerized process (/bin/sh) is moved to cgroup
> > /test before /jdk/bin/java gets executed. Java inherits cgroup /test from
> > its parent process, its _root will be /docker/, cgroup_path
> > will be /test
On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen wrote:
> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash,
>
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more
> testing is needed, so let's roll it back first.
This pull request has now been in
On Sun, 10 Nov 2024 17:51:43 GMT, Doug Lea wrote:
>> This addresses tendencies in previous update to increase fencing, scanning,
>> and signalling that can increase contention, and slow down performance
>> especially on ARM platforms. It also uses more ARM-friendly constructions to
>> reduce o
On Mon, 11 Nov 2024 14:50:57 GMT, Per Minborg wrote:
>> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
>> size of the segments varies.
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes
Hi David,
This is the effect of how parallel streams are implemented, where different
stages, which are not representible as a join-less Spliterator are executed as
a series of "islands" where the next isn't started until the former has
completed.
If you think about it, parallelization of a St
On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen wrote:
> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash,
>
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more
> testing is needed, so let's roll it back first.
CI results look good.
--
On Mon, 11 Nov 2024 13:59:38 GMT, Francesco Nigro wrote:
> Thanks @minborg for this :) Please remember to add the misprediction count if
> you can and avoid the bulk methods by having a `nextMemorySegment()`
> benchmark method which make a single fill call site to observe the different
> segme
> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
> size of the segments varies.
Per Minborg 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 pul
On Mon, 11 Nov 2024 08:13:18 GMT, Jan Lahoda wrote:
>> Currently, running `java` without any parameters will lead to an output that
>> is a full `--help`, which is over 100 lines (on my computer at least), and
>> it feels overwhelming. And many people might actually want to run
>> JShell/REPL,
On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen wrote:
> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash,
>
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more
> testing is needed, so let's roll it back first.
Thanks for the BACKOUT, looks rig
On Mon, 11 Nov 2024 14:16:25 GMT, Alan Bateman wrote:
>> Jan Lahoda 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 11 additional
>> commits sin
On Mon, 11 Nov 2024 08:13:18 GMT, Jan Lahoda wrote:
>> Currently, running `java` without any parameters will lead to an output that
>> is a full `--help`, which is over 100 lines (on my computer at least), and
>> it feels overwhelming. And many people might actually want to run
>> JShell/REPL,
On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen wrote:
> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash,
>
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more
> testing is needed, so let's roll it back first.
I have verified that this backout
On Wed, 30 Oct 2024 05:25:47 GMT, Joe Darcy wrote:
>> Port of Float16 from java.lang in the lworld+fp16 branch to
>> jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback.
src/jdk.i
On Mon, 11 Nov 2024 11:55:27 GMT, Per Minborg wrote:
> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
> size of the segments varies.
Thanks @minborg for this :) Please remember to add the misprediction count if
you can - or just avoid the bulk methods instead i.e.
On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen wrote:
> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash,
>
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more
> testing is needed, so let's roll it back first.
Changes in this area need to be v
And just to avoid the obvious question, I can hold about 30 batches in
memory before the Out of Memory error occurs. So this is not an issue of my
batch size being too high.
But just to confirm, I set the batch size to 1, and it still ran into an
out of memory error. So I feel fairly confident say
This PR proposes to add a new `MemorySegment::fill" benchmark where the byte
size of the segments varies.
-
Commit messages:
- Use static arrays
- Revert changes from other branch
- Add benchmark
- Add benchmarks
Changes: https://git.openjdk.org/jdk/pull/22010/files
Webrev: ht
On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen wrote:
> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash,
>
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more
> testing is needed, so let's roll it back first.
It has been verified that it is c
Hello Core Libs Dev Team,
I was trying out Gatherers for a project at work, and ran into a rather sad
scenario.
I need to process a large file in batches. Each batch is small enough that
I can hold it in memory, but I cannot hold the entire file (and thus, all
of the batches) in memory at once.
On Thu, 6 Jul 2023 17:34:10 GMT, Severin Gehwolf wrote:
> Please review this patch which adds a jlink mode to the JDK which doesn't
> need the packaged modules being present. A.k.a run-time image based jlink.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> insta
On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen wrote:
>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication
>>
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid t
8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash,
so submit this PR to roll back
-
Commit messages:
- Revert "8342650: Move getChars to DecimalDigits"
Changes: https://git.openjdk.org/jdk/pull/22012/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&p
On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen wrote:
>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication
>>
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid t
On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen wrote:
>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication
>>
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid t
On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen wrote:
>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication
>>
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid t
On Thu, 7 Nov 2024 19:09:46 GMT, Per Minborg wrote:
> This PR fixes some regressions in the FFM benchmarks introduced by
> https://bugs.openjdk.org/browse/JDK-8332744.
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/21963#issuecomment-2467974348
On Sun, 20 Oct 2024 17:33:09 GMT, j3graham wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add benchmark
>
> src/java.base/share/classes/java/math/BigDecimal.java line 4216:
>
>> 4214: // Get the significan
Continue to complete PR #16006 to improve performance and reduce duplicate code
-
Commit messages:
- optimize BigDecimal toString/toPlainString
- add benchmark
Changes: https://git.openjdk.org/jdk/pull/22009/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22009&range=00
On Mon, 11 Nov 2024 08:13:18 GMT, Jan Lahoda wrote:
>> Currently, running `java` without any parameters will lead to an output that
>> is a full `--help`, which is over 100 lines (on my computer at least), and
>> it feels overwhelming. And many people might actually want to run
>> JShell/REPL,
On Tue, 5 Nov 2024 19:21:58 GMT, Chen Liang wrote:
>> After the ClassFile API migration, when serializable lambdas are requested
>> for hidden class callers, illegal class name is generated for the
>> serialization methods, which previously had legal yet unusable class names,
>> as hidden clas
On Mon, 11 Nov 2024 08:13:18 GMT, Jan Lahoda wrote:
>> Currently, running `java` without any parameters will lead to an output that
>> is a full `--help`, which is over 100 lines (on my computer at least), and
>> it feels overwhelming. And many people might actually want to run
>> JShell/REPL,
On Mon, 11 Nov 2024 10:06:11 GMT, Severin Gehwolf wrote:
> > I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only.
>
> The JBS issue doesn't mention `NullPointerException`. It would be good to
> list the observed NPE issue.
I also wonder, then, if the issue is NPE if
[JD
On Thu, 7 Nov 2024 13:28:29 GMT, Sergey Chernyshev
wrote:
> Create a new cgroup for memory
>
> ```
> sudo mkdir -p /sys/fs/cgroup/memory/test
> ```
>
> Run the following script
>
> ```
> docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m
> ubuntu:latest \
> sh -c "sleep 10
On Fri, 8 Nov 2024 16:11:37 GMT, Sergey Chernyshev
wrote:
> I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only.
The JBS issue doesn't mention `NullPointerException`. It would be good to list
the observed NPE issue.
-
PR Comment: https://git.openjdk.org/jdk
On Fri, 8 Nov 2024 17:07:55 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> i
On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote:
>>> I do wonder if mutex support can be implemented for Windows with
>>> Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
>>> would be nice to have. Shame threads.h is not available with some Visual
>>> Studio versi
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals that trigger the
> unused warnings and addressed all of them by commenting out th
> Currently, running `java` without any parameters will lead to an output that
> is a full `--help`, which is over 100 lines (on my computer at least), and it
> feels overwhelming. And many people might actually want to run JShell/REPL,
> not the `java` executable, but it is difficult find out a
68 matches
Mail list logo
