On Mon, 14 Jul 2025 15:33:35 GMT, Jorn Vernee wrote:
> Issue copied from the JBS issue:
>
> When an upcall stub accepts a by-value struct, and the struct is passed by
> the underlying ABI as a pointer to a temporary copy on the caller's stack
> (for instance on Windows whe
Issue copied from the JBS issue:
When an upcall stub accepts a by-value struct, and the struct is passed by the
underlying ABI as a pointer to a temporary copy on the caller's stack (for
instance on Windows when the struct doesn't fit into a single register), a
scope is created for the duration
On Tue, 10 Jun 2025 17:01:24 GMT, Per Minborg wrote:
>> This PR proposes to improve the 'MemorySegment.getString(long offset,
>> Charset charset)` method documentation with respect to multi-octet concerns.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit s
On Thu, 22 May 2025 08:31:06 GMT, serhiysachkov wrote:
>> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as
>> manual
>
> serhiysachkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8357462: copyright update
Mark
On Wed, 21 May 2025 13:44:09 GMT, serhiysachkov wrote:
> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as
> manual
Marked as reviewed by jvernee (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/25355#pullrequestreview-2858676969
On Tue, 6 May 2025 22:11:49 GMT, Chen Liang wrote:
>> Credit to @lukellmann that the duplication arg handling in #24742 avoided
>> throwing exceptions but produced a wrong option. This patch fixes that and
>> removed stream usages in CaptureCallState to speed up bootstrap.
>>
>> Also, the prev
On Tue, 6 May 2025 20:07:56 GMT, Chen Liang wrote:
>> Credit to @lukellmann that the duplication arg handling in #24742 avoided
>> throwing exceptions but produced a wrong option. This patch fixes that and
>> removed stream usages in CaptureCallState to speed up bootstrap.
>>
>> Also, the prev
On Tue, 6 May 2025 17:40:52 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java
>> line 55:
>>
>>> 53: } else {
>>> 54: supported = List.of(new CapturableState("errno", JAVA_INT,
>>> 1 << 2));
>>> 55: }
>>
>> Maybe ju
On Tue, 6 May 2025 15:51:54 GMT, Chen Liang wrote:
>> Credit to @lukellmann that the duplication arg handling in #24742 avoided
>> throwing exceptions but produced a wrong option. This patch fixes that and
>> removed stream usages in CaptureCallState to speed up bootstrap.
>>
>> Also, the prev
On Tue, 6 May 2025 15:47:36 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java
>> line 81:
>>
>>> 79:
>>> 80: public static CapturableState forName(String name) {
>>> 81: var ret = LOOKUP.get(name);
>>
>> As we usually have just one
On Tue, 6 May 2025 15:46:22 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java
>> line 59:
>>
>>> 57: MemoryLayout[] stateLayouts = new
>>> MemoryLayout[supported.size()];
>>> 58: @SuppressWarnings({"unchecked", "rawtypes"})
>>>
On Fri, 2 May 2025 11:13:27 GMT, Per Minborg wrote:
>> This PR is based on the work of @mernst-github and aims to implement an
>> _internal_ thread-local 'stack' allocator, which works like a dynamically
>> sized arena, but with reset functionality to reset the allocated size back
>> to a cert
On Thu, 1 May 2025 16:34:14 GMT, Chen Liang wrote:
>> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.
>
> Chen Liang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Review suggestions
Changes look good. Thanks!
--
On Thu, 1 May 2025 10:20:44 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 163:
>>
>>> 161: lock.unlock();
>>> 162: }
>>> 163: Reference.reachabilityFence(arena);
>>
>> I'm not sure t
On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg wrote:
>> This PR is based on the work of @mernst-github and aims to implement an
>> _internal_ thread-local 'stack' allocator, which works like a dynamically
>> sized arena, but with reset functionality to reset the allocated size back
>> to a cer
On Wed, 30 Apr 2025 10:55:41 GMT, Per Minborg wrote:
>> This PR is based on the work of @mernst-github and aims to implement an
>> _internal_ thread-local 'stack' allocator, which works like a dynamically
>> sized arena, but with reset functionality to reset the allocated size back
>> to a cer
On Wed, 23 Apr 2025 22:39:40 GMT, Chen Liang wrote:
> When LambdaForms are interpreted, so are field lambda forms. When this
> happens, we may get into an infinite recursion due to field lambda forms
> using `MethodHandleStatics.UNSAFE` via field lambda form.
>
> I think the best solution here
On Mon, 24 Feb 2025 23:47:02 GMT, Chen Liang wrote:
> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.
The changes look okay. I agree with Jaikiran that adding a stress test for this
would be good.
-
PR Review: https://git.openjdk.org/jdk/pull/23757#pullrequest
On Thu, 24 Apr 2025 10:37:59 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:
>
> Make public constuctor private
The other comments I had were
On Mon, 28 Apr 2025 14:36:33 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
>>
>>
On Sat, 26 Apr 2025 23:47:01 GMT, Chen Liang wrote:
>> Currently, we are not generating all possible field lambda forms.
>>
>> Field lambda forms have these dimensions:
>> - get/set
>> - instance/static/static+class init barrier
>> - plain/volatile
>> - 8 primitive types, no-cast object, object
On Sat, 26 Apr 2025 23:47:01 GMT, Chen Liang wrote:
>> Currently, we are not generating all possible field lambda forms.
>>
>> Field lambda forms have these dimensions:
>> - get/set
>> - instance/static/static+class init barrier
>> - plain/volatile
>> - 8 primitive types, no-cast object, object
On Tue, 29 Apr 2025 19:54:07 GMT, Per Minborg wrote:
> maybe we should problem list or exclude macOS testing?
Yes, I think we should. The issue is quite intermittent, and last time it only
started showing up in CI as well. I think we should move the `stress()` test to
a separate file./jtreg te
On Wed, 23 Apr 2025 14:05:58 GMT, Per Minborg wrote:
> This PR is based on the work of @mernst-github and aims to implement an
> _internal_ thread-local 'stack' allocator, which works like a dynamically
> sized arena, but with reset functionality to reset the allocated size back to
> a certain
On Thu, 24 Apr 2025 10:37:59 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:
>
> Make public constuctor private
Looks mostly good. Left a few
On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore
wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into
>> JDK-8355080
>> - Address henryjen@ c
On Mon, 28 Apr 2025 14:23:53 GMT, Chen Liang wrote:
>> That was from the past attempt of linking Class forName0. Tge exact shape
>> doesn't really matter here as we are mainly saving on DMH.
>
> Can I just change this signature to `FunctionDescriptor.ofVoid()`?
Ok, that makes sense. I suppose i
On Mon, 28 Apr 2025 14:36:33 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
>>
>>
On Mon, 28 Apr 2025 11:29:46 GMT, Maurizio Cimadamore
wrote:
>> Yeah, that was what I was thinking too.
>
> Note - the JEP uses the word `content` (which has, I think, been "vetted").
> So I believe it would be ok (and, preferrable) to leave it as is. Unless you
> are suggesting to also update
On Fri, 18 Apr 2025 18:25:54 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
>>
>>
On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou wrote:
>> Please review this PR that changes to use `NativeLibraries.loadLibrary()`
>> for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>>
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static)
On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore
wrote:
> Having to upgrade to JNI is a bit sad -- although I get that it is required
> as a workaround for now. For the longer term I'd prefer a better way to
> integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary`
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,
1 - 100 of 1124 matches
Mail list logo
