Please review the test fix that removes `libVThreadEventTest` explicit
dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
`Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With
the change, `libVThreadEventTest` no longer needs to be linked with `libj
On Fri, 28 Feb 2025 00:37:24 GMT, Calvin Cheung wrote:
>> A simple fix in `os::jvm_path()` so that gtest can be run with CDS
>> (`-Xshare:on`). The fix is just to change the directory name from `hotspot`
>> to `server`.
>> Note that the bug doesn't exist on macOS and thus no change is required
On Fri, 28 Feb 2025 00:37:24 GMT, Calvin Cheung wrote:
>> A simple fix in `os::jvm_path()` so that gtest can be run with CDS
>> (`-Xshare:on`). The fix is just to change the directory name from `hotspot`
>> to `server`.
>> Note that the bug doesn't exist on macOS and thus no change is required
On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou wrote:
> Please review the test fix that removes `libVThreadEventTest` explicit
> dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
> `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With
> the chang
On Thu, 27 Feb 2025 16:10:17 GMT, Ivan Bereziuk wrote:
>> The output for Jtreg v7.5 was
>> [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947)
>> with [information about skipped
>> tests](https://github.com/openj
> A simple fix in `os::jvm_path()` so that gtest can be run with CDS
> (`-Xshare:on`). The fix is just to change the directory name from `hotspot`
> to `server`.
> Note that the bug doesn't exist on macOS and thus no change is required for
> `os_bsd.cpp`.
>
> Testing:
>
> - run gtest with -Xsh
On Thu, 27 Feb 2025 15:58:55 GMT, Ioi Lam wrote:
>> This is completely wrong.
>>
>> The JVM_CFLAGS_FEATURES should be used to add feature-specific flags, not
>> like this. If we really did want to add this to the CFLAGS for all Hotspot
>> files, the correct thing to do would be to add it to JV
On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou wrote:
> Please review the test fix that removes `libVThreadEventTest` explicit
> dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
> `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With
> the chang
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: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
> 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 main by 47%:
>
> long[] arr = new long[8];
> var ms = Memory
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
> 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 main by 47%:
>
> long[] arr = new long[8];
> var ms = Memory
> The output for Jtreg v7.5 was
> [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947)
> with [information about skipped
> tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#wh
On Thu, 27 Feb 2025 16:10:17 GMT, Ivan Bereziuk wrote:
>> The output for Jtreg v7.5 was
>> [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947)
>> with [information about skipped
>> tests](https://github.com/openj
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?
>
>
On Thu, 27 Feb 2025 10:26:29 GMT, Jorn Vernee wrote:
>> This emulates how MethodHandleImpl does the cache.
>
> Ok. I think the benefit is that each element is individually lazy
> initialized. I'm not sure about the setup with the array though. It seems
> like having 3 stable fields would be sim
18 matches
Mail list logo
