On Fri, 18 Apr 2025 17:56:53 GMT, Chen Liang wrote:
>> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 190:
>>
>>> 188: JAVA_BOOLEAN, ADDRESS, ADDRESS);
>>> 189: Optional symbol =
>>> lookup.find("Java_java_lang_Class_forName0");
>>> 190: var
On Thu, 17 Apr 2025 19:44:07 GMT, Chen Liang wrote:
> Perf numbers for simple main:
> Linking of `Class::forName0` down from ~152 to ~83
>
> For calling little color management system
> https://bugs.openjdk.org/browse/JDK-8313344:
> JNI: ~45
> baseline panama: ~164
> patch: ~103
>
> Also see #
On Thu, 17 Apr 2025 18:03:47 GMT, Vladimir Ivanov wrote:
>> Migrate Vector API math library (SVML and SLEEF) linkage from native code
>> (in JVM) to Java FFM API.
>>
>> Since FFM API doesn't support vector calling conventions yet, migration
>> affects only symbol lookup for now. But it still e
On Thu, 17 Apr 2025 10:47:03 GMT, Viktor Klang wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address comments on original vs underlying
>
> src/java.base/share/classes/java/lang/StableValue.java line 422:
>
>> 42
On Thu, 3 Apr 2025 09:47:15 GMT, Viktor Klang wrote:
>> I think it should be "content" as only one element can be set?
>
> I'm definitely not an expert here, so I'll defer to someone more knowledgable
> :)
I asked around/looked this up, and it seems 'contents' would be more correct
here, since
On Thu, 10 Apr 2025 14:19:25 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Address comments on original vs underlying
Did an initial pa
On Fri, 18 Apr 2025 13:19:05 GMT, Jorn Vernee wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address comments on original vs underlying
>
> src/java.base/share/classes/java/
On Mon, 7 Apr 2025 16:36:07 GMT, Jorn Vernee wrote:
> `jnativescan` uses the `ClassResolver` class to find both system classes, as
> well as application classes. In principle, a class resolver supports both
> iterating over all classes from that particular source, as well as l
On Thu, 10 Apr 2025 17:07:21 GMT, Jorn Vernee wrote:
>> `jnativescan` uses the `ClassResolver` class to find both system classes, as
>> well as application classes. In principle, a class resolver supports both
>> iterating over all classes from that particular source, as well
On Tue, 8 Apr 2025 12:00:41 GMT, Danish Nawab wrote:
>>> This catch block is per-method. It means that if the rest of the method
>>> contained references to restricted methods, we would not see them. The
>>> catch block should be moved to be just around the call to isRestricted,
>>> which can
On Sun, 6 Apr 2025 08:09:27 GMT, Zihao Lin wrote:
>> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET
>> Lambda form. Instead of caching the entire LambdaForm, change it to store a
>> SoftReference. This will avoid unnecessary memory usage.
>
> Zihao Lin has updated the
On Thu, 10 Apr 2025 14:48:59 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains four commits:
>>
>> - Merge branch 'master' into jnativescan_R
I've removed it,
> leaving only its single implementation: `SystemClassResolver`.
>
> Testing: running `langtools_jnativescan` test suite.
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
review comments
-
Chan
I've removed it,
> leaving only its single implementation: `SystemClassResolver`.
>
> Testing: running `langtools_jnativescan` test suite.
Jorn Vernee has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains four commits:
- Merge b
On Tue, 8 Apr 2025 14:47:04 GMT, Per Minborg wrote:
> This PR proposes to use an anonymous class rather than a lambda in order to
> improve startup time.
>
> We need to make sure the regression is fixed by this. It might be the case
> that the regression is there because
> [JDK-8347047](https
On Tue, 8 Apr 2025 13:37:44 GMT, Per Minborg wrote:
> This PR proposes to increase the threshold for `MemorySegment::fill`
> operations on AArch-64 platforms.
>
> Performance looks good:
>
> 
>
> ![image]
On Tue, 8 Apr 2025 13:51:59 GMT, Danish Nawab wrote:
>> ## Description
>>
>> https://bugs.openjdk.org/browse/JDK-8353840
>>
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>>
>>
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit c
On Tue, 8 Apr 2025 12:20:02 GMT, Danish Nawab wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java
>> line 79:
>>
>>> 77: try(ClassResolver classesToScan =
>>> ClassResolver.forClassFileSources(toScan, version);
>>> 78: ClassResolver systemCl
On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab wrote:
> ## Description
>
> https://bugs.openjdk.org/browse/JDK-8353840
>
> ### Existing behavior
> Log the error message and terminate in case of missing system class
>
>
> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab wrote:
> ## Description
>
> https://bugs.openjdk.org/browse/JDK-8353840
>
> ### Existing behavior
> Log the error message and terminate in case of missing system class
>
>
> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
On Tue, 8 Apr 2025 11:41:15 GMT, Jorn Vernee wrote:
>> ## Description
>>
>> https://bugs.openjdk.org/browse/JDK-8353840
>>
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>>
>>
>> $ jnati
On Mon, 7 Apr 2025 16:36:07 GMT, Jorn Vernee wrote:
> `jnativescan` uses the `ClassResolver` class to find both system classes, as
> well as application classes. In principle, a class resolver supports both
> iterating over all classes from that particular source, as well as l
`jnativescan` uses the `ClassResolver` class to find both system classes, as
well as application classes. In principle, a class resolver supports both
iterating over all classes from that particular source, as well as looking up
classes by name. However, the `ClassResolver` for system classes do
Hello,
I had a look here, and can reproduce the error.
jnativescan does have handling for Multi-Release jars. By default it
uses the current JDK version, which in your case would be 24. An exact
version can be specified using --release. The issue in this case is that
the error originates fr
On Thu, 13 Mar 2025 05:46:44 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch improves the performance of a typical `Arena::allocate` in
>> several ways:
>>
>> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge
>> of the instance with the one obtained from the call in
On Tue, 4 Mar 2025 14:17:59 GMT, Chen Liang wrote:
> The LambdaForm will be only used for non-customized bytecode (which cannot
> fully inline anyways)
True, without customization the cases holder in the current implementation will
not be a constant, so we can never inline the cases for shared
On Tue, 4 Mar 2025 14:26:19 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>> line 628:
>>
>>> 626: continue;
>>> 627: }
>>> 628:
On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang wrote:
>> LF editor spins classes, this avoids the spinning overhead and should speed
>> up non-capturing lambdas too.
>>
>> There may need to be additional intrinsic work for MH combinator lf bytecode
>> generation.
>
> Chen Liang has updated the p
On Tue, 4 Mar 2025 14:09:03 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1658:
>>
>>> 1656: var carrier = argument(0, L_TYPE).withConstraint(species); //
>>> BMH bound with data
>>> 1657: Name[] constNames = new Name[] { carrier, ne
On Tue, 4 Mar 2025 14:10:36 GMT, Jorn Vernee wrote:
>> Remove the intrinsicData field. We can obtain this from the customized MH
>> when we spin ultra-customized lambda forms. In the long run, we aim to
>> remove this intrinsic if there is no regression for call site s
On Tue, 4 Mar 2025 14:33:27 GMT, Jorn Vernee wrote:
>> In that case, won't the root form be customized and the table switch names
>> be inlined into the root form?
>
> The root would e.g. have a constant BMH pointing at a _shared_ tableSwitch
> LF. So, the BMH fields
On Tue, 25 Feb 2025 02:45:46 GMT, Chen Liang wrote:
> Remove the intrinsicData field. We can obtain this from the customized MH
> when we spin ultra-customized lambda forms. In the long run, we aim to remove
> this intrinsic if there is no regression for call site sharing.
>
> The existing tab
On Tue, 25 Feb 2025 02:45:46 GMT, Chen Liang wrote:
> The existing tableSwitch combinator's LF is unnecessarily complex. This patch
> also simplifies the tableSwitch combinator.
You're gonna have to explain this. Looking at the code, I think the
optimization here is that, the LambdaForm will j
On Mon, 24 Feb 2025 22:08:53 GMT, Chen Liang wrote:
> we should just select a MH via hash table lookup and invoke that MH
I had something like this in an early prototype of the `tableSwitch`
combinator, but it does not work, as it prevents the method handle calls for
each case from being inlin
On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang wrote:
>> LF editor spins classes, this avoids the spinning overhead and should speed
>> up non-capturing lambdas too.
>>
>> There may need to be additional intrinsic work for MH combinator lf bytecode
>> generation.
>
> Chen Liang has updated the p
On Fri, 28 Feb 2025 15:57:18 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Thu, 27 Feb 2025 16:00:47 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Wed, 26 Feb 2025 19:53:45 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template
>> line 83:
>>
>>> 81: bb.unsafeGetBase(),
>>> 82: offset(bb, base, offset),
>>> 83: handle.be);
>
On Wed, 26 Feb 2025 19:54:59 GMT, Chen Liang wrote:
>> I suggest maybe renaming `noStride` to something like
>> `fixedOffsetInEnclosing`
>
> In last revision I called it `fixedOffset`, but it becomes confusing with the
> actual fixed value of the offset.
Maybe something like `isOffsetFixed` or
On Thu, 27 Feb 2025 13:24:16 GMT, Chen Liang wrote:
> ... creation in clinit is super costly
You mean because threads can not race to initialize? I'd think the extra walks
to create 3 lookups might offset that though...
-
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#
On Wed, 26 Feb 2025 19:56:04 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 74:
>>
>>> 72: return ret;
>>> 73: return computeFilterHandle(index);
>>> 74: }
>>
>> Why is this using an array, instead of just having 3 fields?
>
>
)` which currently is still very
>> slow.
>>
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Jorn vernee review
Some more general questions I have: Using
On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Wed, 26 Feb 2025 17:22:13 GMT, Jorn Vernee wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/in
On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Fri, 21 Feb 2025 10:05:36 GMT, Maurizio Cimadamore
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/VarForm.java li
On Sat, 1 Feb 2025 11:18:18 GMT, Matthias Ernst wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix test under VThread factory
>
> Tried for a few hours to repro with various approaches, to no avail.
@mernst-git
On Wed, 19 Feb 2025 09:14:03 GMT, Per Minborg wrote:
> This PR proposes to clarify the documentation for two of the
> `MemorySegment::reinterpret` overloads.
Marked as reviewed by jvernee (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23688#pullrequestreview-2626820343
On Tue, 4 Feb 2025 09:46:48 GMT, Per Minborg wrote:
> This PR proposes to clarify the documentation for `Arena.ofConfined()`. It is
> proposed to say that segments allocated from the returned `Arena` can _only_
> be accessed by the thread that created the `Arena` in the first place.
Marked as
On Tue, 4 Feb 2025 09:40:02 GMT, Per Minborg wrote:
> This PR proposes to add missing copyright headers to some FFM benchmarks.
Marked as reviewed by jvernee (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23433#pullrequestreview-2592637362
On Thu, 23 Jan 2025 17:36:11 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 Sat, 1 Feb 2025 11:18:18 GMT, Matthias Ernst wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix test under VThread factory
>
> Tried for a few hours to repro with various approaches, to no avail.
@mernst-git
On Wed, 29 Jan 2025 16:15:51 GMT, Jorn Vernee wrote:
> See the JBS issue.
>
> Mark the implementation of `MemorySegment::reinterpret` with `@ForceInline`
> so that we prevent `Reflection.getCallerClass` from falling back to a slow
> stack walk.
>
> This is a lef
On Fri, 31 Jan 2025 15:01:08 GMT, Jorn Vernee wrote:
> This reverts https://github.com/openjdk/jdk/pull/23142
>
> See the JBS issue. It seems that the changes are occasionally causing heap
> corruption, potentially due to use after free, which occasionally results in
> corrupt
On Fri, 31 Jan 2025 15:54:01 GMT, Aleksey Shipilev wrote:
> Backout looks fine. Looks like the clean mechanical `git revert`, and
> therefore trivial.
Yes, it's a clean `git revert`
-
PR Comment: https://git.openjdk.org/jdk/pull/23391#issuecomment-2627694000
On Thu, 23 Jan 2025 17:36:11 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 Thu, 23 Jan 2025 17:36:11 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
This reverts https://github.com/openjdk/jdk/pull/23142
See the JBS issue. It seems that the changes are occasionally causing heap
corruption, potentially due to use after free, which occasionally results in
corrupt malloc headers being caught on mac. This failure was observed once in
about 500
See the JBS issue.
Mark the implementation of `MemorySegment::reinterpret` with `@ForceInline` so
that we prevent `Reflection.getCallerClass` from falling back to a slow stack
walk.
This is a leftover from an earlier performance investigation, in which we
observed `reinterpret` not being inlin
On Mon, 27 Jan 2025 22:06:58 GMT, Jorn Vernee wrote:
> Currently, to free the memory allocated in a confined arena, we keep track of
> a list of 'cleanup actions', stored in linked list format in a so-called
> `ResourceList`, attached to the scope of the arena. When the sco
there are any
> allocations when calling `allocate` on a confined arena. This matches what we
> were doing in the other benchmark methods in the same class.
Jorn Vernee has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelat
Currently, to free the memory allocated in a confined arena, we keep track of a
list of 'cleanup actions', stored in linked list format in a so-called
`ResourceList`, attached to the scope of the arena. When the scope is closed,
we loop over all the entries in this resource list, and run all the
On Tue, 28 Jan 2025 03:31:58 GMT, Chen Liang wrote:
>> Why do you think it should? We never assign the newly allocated resource
>> cleanup to `fst`.
>
> So was the culprit `cleanup.next = fst;`?
Yes, in combination with the while loop which runs all the cleanups, which adds
a phi node that mer
On Tue, 28 Jan 2025 00:08:27 GMT, Chen Liang wrote:
>> Currently, to free the memory allocated in a confined arena, we keep track
>> of a list of 'cleanup actions', stored in linked list format in a so-called
>> `ResourceList`, attached to the scope of the arena. When the scope is
>> closed, w
On Thu, 23 Jan 2025 17:36:11 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 Thu, 23 Jan 2025 18:23:01 GMT, Volodymyr Paprotski
wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> whitespace
>
> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 185:
>
>> 183: // On ECore,
ByValue.byPtravgt 30 3.311 ? 0.034 ns/op
>> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op
>>
>>
>> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160
>> byte/call before.
>
> Matthias Ernst has updated the pu
On Thu, 23 Jan 2025 17:23:48 GMT, Matthias Ernst wrote:
> Need to strategically place yields or interrupt the competitors.
Maybe the number of iterations could be capped?
-
PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2610515954
ByValue.byPtravgt 30 3.311 ? 0.034 ns/op
>> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op
>>
>>
>> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160
>> byte/call before.
>
> Matthias Ernst has updated the pull r
On Thu, 23 Jan 2025 08:33:23 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 15:01:03 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 18:18:47 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 15:01:03 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: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 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: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/CallOverheadByV
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: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
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 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 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 Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote:
>> The idea.sh script which creates a configuration for IDEA does at some point
>> call a makefile, to extract information from the build system. However, this
>> is done in an ad-hoc manner that does not fit properly in the build syst
On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote:
>> The idea.sh script which creates a configuration for IDEA does at some point
>> call a makefile, to extract information from the build system. However, this
>> is done in an ad-hoc manner that does not fit properly in the build syst
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 Thu, 19 Dec 2024 09:48:23 GMT, Per Minborg wrote:
> This PR proposes to improve the current `MemorySegment.toString()` method
> from:
>
> `MemorySegment{ address: 0x6264c540, byteSize: 8 }`
>
> to
>
> `MemorySegment{ native, address: 0x6264c540, byteSize: 8, confined, not
> alive,
On Wed, 18 Dec 2024 16:15:51 GMT, Calvin Cheung wrote:
>> We can not return to native code here in case of an error. We should
>> terminate the process instead.
>>
>> The same should really also be done in case the call to
>> `CallStaticVoidMethod` below throws an exception. This was a leftove
On Tue, 17 Dec 2024 21:43:09 GMT, Calvin Cheung wrote:
> A simple fix for removing an unused variable in fallbacklinker.cpp. This is
> needed for building zero jvm variant on macosx-x64.
>
> Testing:
>
> - [x] tier1
> - [x] zero jvm variant build on macosx-x64
Marked as reviewed by jvernee (R
On Wed, 18 Dec 2024 07:37:49 GMT, Calvin Cheung wrote:
>> Agree with David here. Generally I comment out unused code errors rather
>> than outright remove them for this very reason. Also fallbackLinker doesn't
>> seem to be a C++ file?
>
> How about the following?
>
>
> jint result = (*VM)-
On Tue, 17 Dec 2024 13:45:02 GMT, Jan Kratochvil
wrote:
> There are 2 typos and I find the API a bit complex so it does not help a new
> perplexed user of the API to be additionally confused by typos.
Looks good, thanks for fixing
-
Marked as reviewed by jvernee (Reviewer).
PR R
On Mon, 16 Dec 2024 14:23:26 GMT, Christian Stein wrote:
>> Please review this change ensuring all targeted classes in a MR-JAR file
>> should target the same or a lower classfile version. The [JAR File
>> Specification](https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Multi-release)
>>
On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein wrote:
> Please review this change ensuring all targeted classes in a MR-JAR file
> should target the same or a lower classfile version. The [JAR File
> Specification](https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Multi-release)
> of
On Wed, 11 Dec 2024 19:29:13 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch improves the performance of a typical `Arena::allocate` in
>> several ways:
>>
>> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge
>> of the instance with the one obtained from the call in
On Thu, 12 Dec 2024 15:34:20 GMT, Christian Stein wrote:
> `release of {0} too high: {1}`
I think this is better. Probably good enough.
My concern stems from the fact that 'release' doesn't seem to be defined for
_class files_. I see that the term 'release' exists, and maps to a versioned
dir
On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein wrote:
> Please review this change ensuring all targeted classes in a MR-JAR file
> should target the same or a lower classfile version.
>
> For example, having compiled source files with `javac` 25 without using the
> `--release` option (or wi
On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein wrote:
> Please review this change ensuring all targeted classes in a MR-JAR file
> should target the same or a lower classfile version.
>
> For example, having compiled source files with `javac` 25 without using the
> `--release` option (or wi
On Wed, 11 Dec 2024 15:55:00 GMT, Ivan Šipka wrote:
>> @AlanBateman @mahendrachhipa @bwhuang-us @serhiysachkov @mcimadamore
>> @JornVernee
>>
>> adding as manual tests
>
> Ivan Šipka has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - reve
1 - 100 of 1092 matches
Mail list logo
