> 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
50 matches
Mail list logo
