Re: CFV: New Core Libraries Group Member: Joe Wang

[Per-Ake Minborg]

Vote: Yes.

From: core-libs-dev  on behalf of Lance 
Andersen 
Sent: Friday, July 28, 2023 9:40 PM
To: Roger Riggs ; core-libs-dev 

Subject: Re: CFV: New Core Libraries Group Member: Joe Wang


Vote: Yes.


On 27/07/2023 19:36, Roger Riggs wrote:

I hereby nominate Joe Wang to Membership in the Core Libraries Group

Joe has been working in the core library team since 2012.
He has been maintaining and improving the XML library APIs and implementations
including DOM, SAX, StAX, Transform, Validation, XPath and Catalog.
Recently he has been updating and improving XML Security.

Votes are due by August 11th, 2023.

Only current Members of the Core Libraries Group [1] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs
[2] https://openjdk.org/groups/#member-vote

Re: CFV: New Core Libraries Group Member: Lance Andersen

[Per-Ake Minborg]

Vote: yes

-Per

From: core-libs-dev  on behalf of Roger Riggs 

Sent: Friday, August 25, 2023 5:23 PM
To: core-libs-dev 
Subject: CFV: New Core Libraries Group Member: Lance Andersen


I hereby nominate Lance Andersen to Membership in the Core Libraries Group

Lance has been contributing to the OpenJDK at Oracle since 2007. He has been 
the JDBC spec lead since 2005 and an OpenJDK committer since day 1. He has 
extensive experience with Java EE, Databases and SQL and is improving the 
integrity and performance of Zip and JAR implementations.

Votes are due by September 8th, 2023.

Only current Members of the Core Libraries Group [1] are eligible to vote on 
this nomination. Votes must be cast in the open by replying to this mailing 
list.

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs

[2] https://openjdk.org/groups/#member-vote

Re: CFV: New Core Libraries Group Member: Daniel Fuchs

[Per-Ake Minborg]

Vote: yes


  *   Per


From: core-libs-dev  on behalf of Roger Riggs 

Sent: Friday, August 25, 2023 5:23 PM
To: core-libs-dev 
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs

I hereby nominate Daniel Fuchs to Membership in the Core Libraries Group

Daniel has been contributing to the OpenJDK Core Libraries at Oracle
since 2012. He is leading the networking team and has made nearly 400
contributions to OpenJDK since JDK 6.

Votes are due by September 8th, 2023.

Only current Members of the Core Libraries Group [1] are eligible to
vote on this nomination. Votes must be cast in the open by replying to
this mailing list.

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs

[2] https://openjdk.org/groups/#member-vote

Re: CFV: New Core Libraries Group Member: Michael McMahon

[Per-Ake Minborg]

Vote: yes

-Per

From: core-libs-dev  on behalf of Roger Riggs 

Sent: Friday, August 25, 2023 5:24 PM
To: core-libs-dev 
Subject: CFV: New Core Libraries Group Member: Michael McMahon

I hereby nominate Michael McMahon to Membership in the Core Libraries Group

Michael has been contributing to the OpenJDK Core Libraries since 2008,
originally at Sun Microsystems, now Oracle. He has deep networking
experience and has made more than 260 contributions to OpenJDK.

Votes are due by September 8th, 2023.

Only current Members of the Core Libraries Group [1] are eligible to
vote on this nomination. Votes must be cast in the open by replying to
this mailing list For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs

[2] https://openjdk.org/groups/#member-vote

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview)

[Per-Ake Minborg]

Hi Remi and thank you for the feedback from JChateau (what a wonderful name!).

This is one of the issues we already have on the list for the next round of 
preview. Now we know more folks are on the same page.

Best, Per

From: Remi Forax 
Sent: Wednesday, April 2, 2025 4:33 PM
To: Per Minborg 
Cc: compiler-dev ; core-libs-dev 
; hotspot-dev ; 
security-dev 
Subject: Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview)

Hi Per,
last week, at JChateau, we had a one hour session about stable values, I've 
build the JDK with this PR so we can discuss about it.

To present the API, i start from the double check locking, rewriting it to use 
the StableValue API.

The main remark was that methods like orElseSet() or isSet() are hard to used 
correctly.

In my opinion, the current API is a mix of a high level API and a low-level API 
but it's too easy to misuse the low-level API.


high level:
- methods supplier(), list() and map()
  Those are easy to use

low level:
- methods: of, of(value), orElseSet, setOrThrow(), etc
  Those are hard to use properly.

I think, not necessary in this PR, that the current API should be separated 
into two different classes, one in java.lang with the high level API (the 
static methods other than Of() and one in java.util.concurrent with the low 
level API where you have to know what you are doing (like with any classes of 
java.util.concurrent).

regards,
Rémi

- Original Message -
> From: "Per Minborg" 
> To: "compiler-dev" , "core-libs-dev" 
> , "hotspot-dev"
> , "security-dev" 
> Sent: Thursday, March 13, 2025 12:20:10 PM
> Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)

> Implement JEP 502.
>
> The PR passes tier1-tier3 tests.
>
> -
>
> Commit messages:
> - Use acquire semantics for reading rather than volatile semantics
> - Add missing null check
> - Simplify handling of sentinel, wrap, and unwrap
> - Fix JavaDoc issues
> - Fix members in StableEnumFunction
> - Address some comments in the PR
> - Merge branch 'master' into implement-jep502
> - Revert change
> - Fix copyright issues
> - Update JEP number
> - ... and 231 more: https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6
>
> Changes: https://git.openjdk.org/jdk/pull/23972/files
>  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8351565
>  Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod
>  Patch: https://git.openjdk.org/jdk/pull/23972.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972
>
> PR: https://git.openjdk.org/jdk/pull/23972

Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5]

[Per-Ake Minborg]

Hi Archie!

The C2 compiler can use automatic vectorization [1] to speed up such 
operations. You can watch my explanation of the concept in some of my recent 
presentations, e.g, [2]

Best, Per
YouTube
Share your videos with friends, family, and the world
youtu.be

Automatic vectorization - 
Wikipedia
Automatic vectorization, in parallel computing, is a special case of automatic 
parallelization, where a computer program is converted from a scalar 
implementation, which processes a single pair of operands at a time, to a 
vector implementation, which processes one operation on multiple pairs of 
operands at once. For example, modern conventional computers, including 
specialized supercomputers ...
en.wikipedia.org
[1] https://en.wikipedia.org/wiki/Automatic_vectorization
[2] https://youtu.be/rXv2-lN5Xgk?t=1518

From: core-libs-dev  on behalf of Archie Cobbs 

Sent: Thursday, May 22, 2025 10:58 PM
To: John R Rose 
Cc: core-libs-dev@openjdk.org 
Subject: Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can be 
improved using overlaps [v5]

On Thu, May 22, 2025 at 3:31 PM John R Rose 
mailto:jr...@openjdk.org>> wrote:
>   Update benchmark to reflect new fill method

Related discussion at the hardware level:

https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076

This discussion spurred me to ask a dumb question. Apologies in advance, just 
trying to learn here...

If I do this:

import java.util.Arrays;
public class ArrayFiller {
public static void main(String[] args) {
while (true) {
final byte[] array = new byte[100];
Arrays.fill(array, (byte)0x42);
}
}
}

Will C2 compile 
Arrays.fill()
 into something that is more efficient than a byte-at-a-time loop like what 
appears in the source code?

Thanks,
-Archie

--
Archie L. Cobbs

Re: Interest in Java based attach provider implementation?

[Per-Ake Minborg]

Hi Philippe!

Thanks for your interest and efforts in modernizing the JDK to use the FFM API 
to replace older code. As mentioned before, we are running an effort called 
"Panamization" within the JDK community to push in this direction.

Here is an example of a PR that might be helpful when writing such code: 
https://github.com/openjdk/jdk/pull/25546


[https://opengraph.githubassets.com/072f4c9fd78eedb780c9b704f4f6470ace3a8c466871641aa051ad542f972791/openjdk/jdk/pull/25546]
WIP: Panamize KQueue selector implementation by DarraghClarke · Pull Request 
#25546 · openjdk/jdk
This is a draft to hopefully facilitate some discussions and feedback about the 
panamization of Kqueue This is based on the work that was previously shared in 
#22307 , The main change since then is...
github.com
I am willing to help/sponsor your efforts. Maybe we could start with 3. kill, 
which seems to be a low-hanging fruit. Making this consistent with the above PR 
would be a good first step.

I will contact you directly via the above email.

Best, Per Minborg


From: core-libs-dev  on behalf of Philippe 
Marschall 
Sent: Tuesday, June 24, 2025 4:30 PM
To: Magnus Ihse Bursie ; 
serviceability-...@openjdk.java.net ; 
core-libs-dev 
Subject: Re: Interest in Java based attach provider implementation?

Hello

Since the audience has been expanded let me summarize what would be
needed to make jdk.attach free of JNI on Unix (AIX, Linux, macOS).
jdk.attach currently uses JNI for four different things.

1. reading and writing unix domain sockets
2. accessing uid, guid and permissions of a file
3. sending SIGQUIT to an arbitrary PID, including self in the case of
self attach
4. sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, pid}) on macOS

For 1. and 2. there are already supported Java based APIs and I have
patches in case somebody is willing to sponsor this work / open a JIRA.

3. kill(SIGQUIT)

This can be done quite easily using FFM as the signature of kill() is
quite simple. The signature and values are the same an Linux and macOS
and I assume AIX as well, but I don't have access to a machine to
verify. Overlap with existing code is with ProcessHandleImpl.destroy0
which sends SIGKILL or SIGTERM to a PID but performs additional checks.
So an API to send a signal to a PID would be needed. It is my
understanding that jdk.internal.misc.Signal only supports sending signal
to self.

4. sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, pid})

This is more complicated as the kinfo_proc and extern_proc structs are
quite large. jextract is the easiest way to come up with the
definitions. However the amount of generated code is quite large even
after filtering. The generated code can be further cut down using manual
editing. I have not yet looked into replacing not needed struct fields
with padding. To the best of my knowledge jextract hasn't the been
included into the JDK build.
Overlap here is in ProcessHandleImpl_macosx.c with the functions
os_getParentPidAndTimings and getUID but they access different fields of
extern_proc.
Honestly here I'm not sure why this check is needed at all. The
reasoning given for the check in VirtualMachineImpl.c would in my option
apply to Linux and AIX as well but this check is not performed there.
Removing this check from the macOS implementation would obviously be the
easiest.

I can't speak for Windows as I'm not familiar enough with Windows APIs.

Cheers
Philippe


On 19.06.25 14:40, Magnus Ihse Bursie wrote:
> Hi Philippe,
>
> There is an ongoing effort about "Panamization" (that is, adapting it to
> use FFM instead of JNI) of native code in the JDK in general. This is
> discussed on the core-libs-dev mailing list. I've cc:ed them. I think it
> would be beneficial if you coordinate your efforts with the Panamization
> effort.
>
> /Magnus
>
>
> On 2025-06-15 17:43, Philippe Marschall wrote:
>> Hello
>>
>> I further pursued the approach
>>
>> - Rebased the Linux implementation [1], implemented the permission
>> check using JSR 203 and the Unix domain sockets using JEP 380.
>> - Applied the same changes to the AIX implementation [2].
>> - Switched Linux to an FFM based kill implementation [3], completely
>> getting rid of JNI.
>> -  Updated the macOS implementation [4], implemented the permission
>> check using JSR 203 and the Unix domain sockets using JEP 380.
>> - Switched macOS to an FFM based kill and sysctl implementation [5],
>> completely getting rid of JNI.
>>
>> I ran the serviceability test suite on Linux and macOS and it passes.
>> I manually verified that I can attach to JVMs using local builds.
>>
>> I could not test on AIX.
>>
>>  [1] https://github.com/marschall/jdk/
>> commit/3a7796daadad7c9d2d85e9e4623f170baecc0e41
>>  [2] https://github.com/marschall/jdk/
>> commit/962729e0bfb6b7d86af303f25c6670d407d1d2d9
>>  [3] https://github.com/marschall/jdk/
>> commit/7b5f1bf6f55458a7f69f50b8fdf4986e

Re: Best Practice for Busy Waiting in Java

[Per-Ake Minborg]

Hi Markus, and thank you for your question, which I think is a very relevant 
one.

There is no silver bullet here. It all depends on the problem at hand. One of 
the major questions to ask is what the aim of the solution is: are you 
optimizing latency, throughput, power efficiency, fairness, a certain SLA etc.

If you have considered asynchronous programming, I would encourage you to 
instead take a look at virtual threads, which provide a much more robust 
programming model. I think this is, indeed, a best practice approach in this 
type of choices.

If you are dealing with latency sensitive stuff, sometimes starting out with a 
busy wait (calling Thread.onSpinWait()) and then progressively backing off to 
yield() and wait() could be a good strategy. This can be combined with thread 
pinning and CPU isolation on the OS level to get improved latency metrics. 
Sometimes, event loops are a good choice in this domain.

Best, Per Minborg

From: core-libs-dev  on behalf of Chen Liang 

Sent: Sunday, June 15, 2025 10:42 PM
To: Markus KARG ; Archie Cobbs 
Cc: core-libs-dev 
Subject: Re: Best Practice for Busy Waiting in Java

Not a concurrency professional, but my first impression is whether to yield or 
spin depends on how costly the task you are waiting is - I know yield involves 
a context switch and can be problematic for small waits.

In addition, in Java, many blocking happens in a way users cannot control - for 
example, class initialization. Those might be bigger bottlenecks compared to 
the explicit busy waits.

Chen


Get Outlook for Android

From: core-libs-dev  on behalf of Markus KARG 

Sent: Sunday, June 15, 2025 11:49:52 AM
To: Archie Cobbs 
Cc: core-libs-dev 
Subject: Re: Best Practice for Busy Waiting in Java


Seems you misunderstood my question. It was *not* what is best to do. It was: 
"Does the core-libs team have a common-sense / best practice for busy-wait.". 
The latter is a clear and concise question, and the answer could be as simple 
as "yes" or "no".

Am 15.06.2025 um 18:40 schrieb Archie Cobbs:
Just MHO...

This is kind of like asking "What's the best way to waste electricity?"

It's a nebulous question until you specify what "best" means in this odd 
scenario

-Archie

On Sun, Jun 15, 2025 at 11:09 AM Markus KARG 
mailto:mar...@headcrashing.eu>> wrote:
Recently I was asked by a programmer, what to do if there simply is no
other way than actually busy-wait.

I see several options:

* Do nothing: Costs valuable CPU time and increases carbon footprint.

* Do a power-nap: Thread.sleep(1)

* Be fair: Thread.yield() gives other threads a chance to execute in
this time slot.

* Be eco-friendly: Thread.onSpinWait() could reduce carbon footprint.

* A combination of that, like "Thread.yield(); Thread.onSpinWait();"

As all of that has its pros and cons, and as all of that works
differently on each hardware platform, I do wonder if there is some
common sense / best practice for busy wait (other than "Replace it using
async") in the core-libs team?

Thanks!

-Markus





--
Archie L. Cobbs

Re: FFM - Optimizing string reads in MemorySegment

[Per-Ake Minborg]

Hi Liam!

Thank you for your comments on MemorySegment::getString !

The intention was that the creation of the intermediate array should be elided, 
but as you point out, that is (at least sometimes) not the case. I've made an 
experimental patch where I've used JavaLangAccess::uncheckedNewStringNoRepl in 
StringSupport which looks promising:


Base:
ToJavaStringTest.panama_readString   5 avgt 30 13.559 ± 0.246 ns/op
ToJavaStringTest.panama_readString  20 avgt 30 67.047 ± 7.541 ns/op <- Slow
ToJavaStringTest.panama_readString 100 avgt 30 28.092 ± 0.547 ns/op
ToJavaStringTest.panama_readString 200 avgt 30 37.679 ± 0.645 ns/op
ToJavaStringTest.panama_readString 451 avgt 30 64.544 ± 1.096 ns/op

Experimental Patch:
ToJavaStringTest.panama_readString   5 avgt 30 8.847 ± 0.178 ns/op
ToJavaStringTest.panama_readString  20 avgt 30 20.332 ± 4.495 ns/op
ToJavaStringTest.panama_readString 100 avgt 30 21.808 ± 0.315 ns/op
ToJavaStringTest.panama_readString 200 avgt 30 28.711 ± 0.105 ns/op
ToJavaStringTest.panama_readString 451 avgt 30 51.806 ± 1.067 ns/op


So, this indicates that there are gains to be made here, although the ultimate 
solution might be something else (such as improving inlining). I have raised an 
issue for this.

Thanks again for bringing this to the general knowledge.

Best,
Per Minborg
Oracle Core Libraries

From: core-libs-dev  on behalf of Liam 
Miller-Cushon 
Sent: Friday, July 18, 2025 7:26 PM
To: OpenJDK Core Libs Developers 
Subject: FFM - Optimizing string reads in MemorySegment

Hi,

I have a question about the performance of string reads in MemorySegment.

There was some discussion about reading strings with known lengths in 
JDK-8333843, and the outcome was to update the getString javadoc to recommend:

byte[] bytes = new byte[length];
MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
return new String(bytes, charset);

As I understand it that's as efficient as what MemorySegment#getString is doing 
under the hood, the main difference with getString is that it's first reading 
the length of a null-terminated string, but after that it just uses 
MemorySegment.copy and calls the String constructor.

Has avoiding the byte[] copy in the String constructor been considered?

In theory it might be possible for the runtime to inline the String 
constructor, see that the byte[] doesn't escape, and skip the copy. In 
practice, based on some benchmarking my colleague Louis Wasserman was doing, 
that doesn't seem to be happening.

Would it make sense to consider using JavaLangAccess#uncheckedNewStringNoRepl 
here to avoid having to copy the byte[]?

Thanks,
Liam