On Thu, 8 May 2025 10:50:55 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Thu, 8 May 2025 09:21:42 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address comments
>
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 15520:
>
>> 15518:
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Thu, 8 May 2025 08:47:50 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove class
>
> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line
> 110:
>
>> 108:
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Thu, 8 May 2025 09:21:35 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Thu, 8 May 2025 07:54:17 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Thu, 8 May 2025 07:54:17 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Thu, 8 May 2025 07:54:17 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Thu, 8 May 2025 07:40:44 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Wed, 7 May 2025 03:19:53 GMT, Shaojin Wen wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address comments
>
> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line
> 78:
>
>> 76:
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Wed, 7 May 2025 03:05:31 GMT, Shaojin Wen wrote:
>> enhanced 'switch' is just syntax sugar and does not affect startup speed
>
> I looked at the generated bytecode through javap and confirmed that the
> enhanced switch is just syntactic sugar and no additional classes are
> generated.
Thank
On Tue, 6 May 2025 12:32:38 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Tue, 6 May 2025 12:32:38 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Tue, 6 May 2025 12:32:38 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Tue, 6 May 2025 17:16:32 GMT, Shaojin Wen wrote:
>> I have the old switch format in anticipation of faster startup.
>
> enhanced 'switch' is just syntax sugar and does not affect startup speed
I looked at the generated bytecode through javap and confirmed that the
enhanced switch is just syn
On Tue, 6 May 2025 12:30:01 GMT, Per Minborg wrote:
>> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line
>> 390:
>>
>>> 388: return MhUtil.findVirtual(LOOKUP, Arena.class, "close",
>>> 389: MethodType.methodType(void.class));
>>>
On Tue, 6 May 2025 08:47:54 GMT, Shaojin Wen wrote:
>> Per Minborg has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Fix empty line at the end of a third file
>> - Fix empty line at the end of another file
>> - Fix empty line at the
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Tue, 6 May 2025 09:21:24 GMT, Shaojin Wen wrote:
>> Per Minborg has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Fix empty line at the end of a third file
>> - Fix empty line at the end of another file
>> - Fix empty line at the
On Mon, 5 May 2025 18:21:44 GMT, ExE Boss wrote:
>> Per Minborg has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Fix empty line at the end of a third file
>> - Fix empty line at the end of another file
>> - Fix empty line at the end
On Mon, 5 May 2025 17:13:02 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Mon, 5 May 2025 17:13:02 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Mon, 5 May 2025 17:13:02 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Mon, 5 May 2025 17:13:02 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Mon, 5 May 2025 17:13:02 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Mon, 5 May 2025 16:53:58 GMT, Per Minborg wrote:
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negativ
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
As we advance, converting older JDK code to use the relatively new FFM API
requires system calls that can provide `errno` and the likes to explicitly
allocate a MemorySegment to capture potential error states. This can lead to
negative performance implications if not designed carefully and also
On Tue, 29 Apr 2025 12:33:34 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a `MemorySegment` to capture potential error states. This can lead
>> to
On Tue, 29 Apr 2025 12:33:34 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a `MemorySegment` to capture potential error states. This can lead
>> to
On Tue, 29 Apr 2025 12:33:34 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a `MemorySegment` to capture potential error states. This can lead
>> to
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
On Thu, 13 Mar 2025 15:21:33 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a `MemorySegment` to capture potential error states. This can lead
>> to
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
On Wed, 26 Feb 2025 05:00:09 GMT, Chen Liang wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a `MemorySegment` to capture potential error states. This can lead
>> to n
On Tue, 25 Feb 2025 08:27:26 GMT, Per Minborg wrote:
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to nega
As we advance, converting older JDK code to use the relatively new FFM API
requires system calls that can provide `errno` and the likes to explicitly
allocate a `MemorySegment` to capture potential error states. This can lead to
negative performance implications if not designed carefully and als
On Wed, 12 Feb 2025 16:04:53 GMT, Per Minborg wrote:
>> Going forward, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a `MemorySegment` to capture potential error states. This can lead
>> to
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a `MemorySegment` to capture potential error states. This can lead
> to negative performance implications if not designed carefully
Going forward, converting older JDK code to use the relatively new FFM API
requires system calls that can provide `errno` and the likes to explicitly
allocate a `MemorySegment` to capture potential error states. This can lead to
negative performance implications if not designed carefully and als
On Thu, 16 Jan 2025 14:16:15 GMT, Matthias Ernst wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unused class
>
> src/java.base/share/classes/jdk/internal/util/SingleElementPool.java line 132:
>
>> 130:
On Thu, 16 Jan 2025 11:58:20 GMT, Per Minborg wrote:
>> Going forward, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> ne
On Thu, 16 Jan 2025 11:58:20 GMT, Per Minborg wrote:
>> Going forward, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> ne
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Wed, 15 Jan 2025 16:13:38 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Use invokeExact semantics in the tests
>> - Clean up
>
> src/java.base/share/classes/jdk/internal/foreign/Cap
On Wed, 15 Jan 2025 15:51:49 GMT, Per Minborg wrote:
> > So, as we foresee the adoption of the FFM API in the JDK internals, we will
> > use such a mechanism for system calls like `fopen`, `socket`, and the like.
> > See #22307 for example.
>
> Sorry I still don't see where you do the actual na
On Wed, 15 Jan 2025 16:09:36 GMT, Per Minborg wrote:
>> Going forward, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> ne
On Wed, 15 Jan 2025 16:09:36 GMT, Per Minborg wrote:
>> Going forward, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> ne
On Wed, 15 Jan 2025 16:09:36 GMT, Per Minborg wrote:
>> Going forward, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> ne
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Tue, 14 Jan 2025 12:29:11 GMT, David Holmes wrote:
> > So, as we foresee the adoption of the FFM API in the JDK internals, we will
> > use such a mechanism for system calls like `fopen`, `socket`, and the like.
> > See #22307 for example.
>
> Sorry I still don't see where you do the actual n
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Tue, 14 Jan 2025 15:59:42 GMT, Per Minborg wrote:
>> Going forward, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> ne
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Mon, 13 Jan 2025 11:07:11 GMT, Per Minborg wrote:
>> Going forward, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> ne
On Tue, 14 Jan 2025 07:31:08 GMT, Per Minborg wrote:
>> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line
>> 214:
>>
>>> 212: // Used reflectively by `getAsIntHandle(MemoryLayout layout)`
>>> 213: private static int getStateAsInt(VarHandle handle) {
>>> 214:
On Mon, 13 Jan 2025 11:06:36 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Clean up benchmark
>> - Fix allocation problem in benchmark
>
> src/java.base/share/classes/jdk/internal/fore
On Tue, 14 Jan 2025 06:29:36 GMT, David Holmes wrote:
> Where do you actually make the native call and grab the errno/last-error
> value?
So, as we foresee the adoption of the FFM API in the JDK internals, we will use
such a mechanism for system calls like `fopen`, `socket`, and the like.
Se
On Mon, 13 Jan 2025 11:07:11 GMT, Per Minborg wrote:
>> Going forward, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> ne
On Mon, 13 Jan 2025 10:11:27 GMT, Per Minborg wrote:
>> Going forward, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> ne
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Fri, 10 Jan 2025 09:41:34 GMT, Alan Bateman wrote:
>> Per Minborg has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Clean up benchmark
>> - Fix allocation problem in benchmark
>
> src/java.base/share/classes/jdk/internal/foreign/Capt
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Tue, 26 Nov 2024 15:04:51 GMT, Per Minborg wrote:
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negati
Going forward, converting older JDK code to use the relatively new FFM API
requires system calls that can provide `errno` and the likes to explicitly
allocate a MemorySegment to capture potential error states. This can lead to
negative performance implications if not designed carefully and also
On Tue, 26 Nov 2024 15:04:51 GMT, Per Minborg wrote:
> Going forward, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negati
89 matches
Mail list logo
