> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Wed, 22 Jan 2025 12:36:17 GMT, Matthias Ernst wrote:
>> On another note: in principle if a Frame is not the latest returned in a
>> given thread, it is not safe to allow its allocation method (and probably
>> close too) to succeed. Consider this case:
>>
>>
>> Arena arenaOuter = bufferStac
On Wed, 22 Jan 2025 11:05:14 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line
>> 38:
>>
>>> 36: @SuppressWarnings("restricted")
>>> 37: public MemorySegment allocate(long byteSize, long
>>> byteAlignment) {
>>> 38:
On Wed, 22 Jan 2025 10:40:07 GMT, Maurizio Cimadamore
wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> --unnecessary annotations
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 17:
On Wed, 22 Jan 2025 11:50:10 GMT, Jorn Vernee wrote:
>> I'm told that TerminatingThreadLocal runs the "terminate" action for an
>> object T from the same thread T refers to. So, in principle, using a
>> TerminatingThreadLocal + confined arena should be ok.
>>
>> If that works, I'd suggest to c
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Wed, 22 Jan 2025 10:52:57 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line
>> 389:
>>
>>> 387: @Override
>>> 388: protected BufferStack initialValue() {
>>> 389: return new BufferStack(Arena.ofAuto().al
On Wed, 22 Jan 2025 10:43:27 GMT, Maurizio Cimadamore
wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> --unnecessary annotations
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 38:
On Wed, 22 Jan 2025 10:05:31 GMT, Matthias Ernst wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Back buffer allocation with a single carrier-local segment.
>
> src/java.base/share/classes/jdk/internal/foreign/ab
On Wed, 22 Jan 2025 10:12:13 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Wed, 22 Jan 2025 10:12:13 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Wed, 22 Jan 2025 10:12:13 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Wed, 22 Jan 2025 10:12:13 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Wed, 22 Jan 2025 10:12:13 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Wed, 22 Jan 2025 09:57:15 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Wed, 22 Jan 2025 09:57:15 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Tue, 21 Jan 2025 17:04:01 GMT, Jorn Vernee wrote:
> Talking to Maurizio offline, and we realized that if we just pin the
> continuation when we acquire the buffer, and unpin when releasing, we don't
> have to worry about buffers floating between threads between acquire &
> release, and we c
On Mon, 20 Jan 2025 18:43:54 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 18:39:06 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> whitespace :scream:
>
> test/jdk/java/foreign/CallBufferCacheTest.java line 95:
>
>> 93: assertTrue(CallBuffe
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Mon, 20 Jan 2025 18:33:55 GMT, Jorn Vernee wrote:
>> test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line
>> 54:
>>
>>> 52: @State(org.openjdk.jmh.annotations.Scope.Thread)
>>> 53: @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>> 54: @Fork(value = 1, jvmArgs = {"--enable-nat
On Mon, 20 Jan 2025 18:13:53 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 18:32:55 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> whitespace :scream:
>
> test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line
> 54:
>
>> 52:
On Mon, 20 Jan 2025 18:13:53 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 18:15:11 GMT, Jorn Vernee wrote:
>> That was my original version, but this proved to be faster (albeit very
>> little, O(.5ns)). I can't really explain why, that's above my paygrade, but
>> one thing that comes to mind when storing references is that there's might
>> be a G
On Mon, 20 Jan 2025 18:09:56 GMT, Matthias Ernst wrote:
> Footprint reduction would be 8 bytes * #carrier threads, and with scalar
> replacement, ofAddress should become a noop, right?
Yes.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922741985
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Mon, 20 Jan 2025 17:27:40 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - shift api boundary
>> - move bench
>> - revert formatting
>
> src/java.base/share/classes/jdk/internal/foreign/a
On Mon, 20 Jan 2025 17:34:45 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java
>> line 112:
>>
>>> 110:
>>> 111: @SuppressWarnings("restricted")
>>> 112: public static MemorySegment acquireOrAllocate(long requestedSize) {
>>
On Mon, 20 Jan 2025 17:22:09 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - shift api boundary
>> - move bench
>> - revert formatting
>
> test/micro/org/openjdk/bench/java/lang/foreign/Cal
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Mon, 20 Jan 2025 16:34:15 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 17:33:01 GMT, Maurizio Cimadamore
wrote:
> An even higher-level alternative here would be for this method to return a
> custom arena, whose `close` implementation does the `release`. This way, no
> cleanup action is needed. The arena could use a slicing allocator on a
> pr
On Mon, 20 Jan 2025 16:20:20 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 16:20:20 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 15:03:37 GMT, Maurizio Cimadamore
wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implementation notes.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java
> line 9
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Mon, 20 Jan 2025 15:00:55 GMT, Maurizio Cimadamore
wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implementation notes.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java
> line 7
On Mon, 20 Jan 2025 14:06:33 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implementation notes.
>
> test/micro/org/openjdk/bench/java/lang/foreign/points/PointsAlloc.java line
> 81:
>
>> 79:
On Mon, 20 Jan 2025 15:00:14 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line
>> 396:
>>
>>> 394: long address = fromCache != 0 ? fromCache :
>>> CallBufferCache.allocate(bufferSize);
>>> 395: return new
>>> Bounded
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Mon, 20 Jan 2025 13:43:35 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implementation notes.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line
> 396:
>
>> 394
On Mon, 20 Jan 2025 07:30:17 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Mon, 20 Jan 2025 07:30:17 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
> Certain signatures for foreign function calls require allocation of an
> intermediate buffer to adapt the FFM's to the native stub's calling
> convention ("needsReturnBuffer"). In the current implementation, this buffer
> is malloced and freed on every FFM invocation, a non-negligible overhead
On Wed, 15 Jan 2025 21:39:05 GMT, Matthias Ernst wrote:
> Certain signatures for foreign function calls require allocation of an
> intermediate buffer to adapt the FFM's to the native stub's calling
> convention ("needsReturnBuffer"). In the current implementation, this buffer
> is malloced an
On Fri, 17 Jan 2025 14:58:37 GMT, Jorn Vernee wrote:
> Could you add the benchmark you're using to the PR as well?
Done. I slotted it into the "points" BM suite, alas I had to define another
"DoublePoint" struct, though, since the existing int/int pair gets packed into
a long.
Full disclosur
Certain signatures for foreign function calls require allocation of an
intermediate buffer to adapt the FFM's to the native stub's calling convention
("needsReturnBuffer"). In the current implementation, this buffer is malloced
and freed on every FFM invocation, a non-negligible overhead.
Sampl
51 matches
Mail list logo
