On Thu, 29 Aug 2024 17:55:53 GMT, Markus Grönlund wrote:
>> narrowKlass is the result of encoding Klass* with
>> CompressedKlassPointers::encode() which is relative to the compressed base,
>> so if UseCompressedClassPointers is false then the encoding to narrowKlass
>&
On Thu, 29 Aug 2024 17:46:11 GMT, Coleen Phillimore wrote:
>> It's fine to have each Klass* report whether it can be compressed. If not,
>> it will be represented using the non-compressed version, which will be a bit
>> more bloated, but no problems.
>
> narrowKlass is the result of encoding Kl
On Thu, 29 Aug 2024 17:42:20 GMT, Markus Grönlund wrote:
>> Its very rare, if at all, that an abstract or an interface would be tagged
>> in JFR. Tags are for concrete implementations, mostly InstanceKlass*.
>
> I now read the JIRA issue. JFR do process loads of
> java/l
On Thu, 29 Aug 2024 17:35:07 GMT, Markus Grönlund wrote:
>> In summary, we are agnostic about which space the Klass* is located in; we
>> only care if a valid means exists to perform an encode() and decode()
>> operation to compress the Klass* (for 64-bit to be clear). This
On Thu, 29 Aug 2024 17:30:26 GMT, Markus Grönlund wrote:
>> // Return TRUE only if UseCompressedClassPointers is True.
>> static bool using_class_space() {
>> return NOT_LP64(false) LP64_ONLY(UseCompressedClassPointers);
>> }
>>
>> I see now that
On Thu, 29 Aug 2024 17:26:57 GMT, Markus Grönlund wrote:
>> The code supports the JfrTraceID load barrier that enqueues tagged Klass*.
>> It selects a more compact representation (a single word, instead of two
>> words), if a Klass* can be compressed (i.e. there exist
On Thu, 29 Aug 2024 17:24:47 GMT, Markus Grönlund wrote:
>> With UseCompressedClassPointers off, I think
>> Metaspace::is_in_shared_metaspace() would still return true but I don't
>> think he compression base is the bottom of the CDS archive. I asked Markus
>>
On Thu, 29 Aug 2024 15:45:17 GMT, Coleen Phillimore wrote:
>> If UseCompressedClassPointers is off, we don't have a compressed class
>> space. If its on, Klass from CDS and from class space are compressable. With
>> your patch, interfaces will live in normal metaspace, not int class space,
>>
On Wed, 14 Aug 2024 20:53:33 GMT, Markus Grönlund wrote:
> Greetings,
>
> Explicitly pin a virtual thread before acquiring the JFR string pool monitor
> because migrating a carrier thread local event writer object onto another
> carrier thread is impossible.
>
> Dur
On Wed, 21 Aug 2024 20:11:05 GMT, Markus Grönlund wrote:
> Greetings,
>
> Please help review this change set that implements C2 intrinsics for
> jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
>
> This work is a consequence of
>
On Thu, 22 Aug 2024 15:51:49 GMT, Vladimir Kozlov wrote:
>> Markus Grönlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JVMCI exportation
>
> Marked as reviewed by kvn (Reviewer).
Thank you for your r
On Fri, 23 Aug 2024 07:35:05 GMT, Alan Bateman wrote:
>> Markus Grönlund has updated the pull request incrementally with five
>> additional commits since the last revision:
>>
>> - pin state conditional delivered using event writer object
>> - Merge branch &#
On Thu, 22 Aug 2024 11:27:27 GMT, Yudi Zheng wrote:
>> Markus Grönlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JVMCI exportation
>
> src/hotspot/share/opto/library_call.cpp line 3733:
>
plicit and to access it uniformly from the
> intrinsic code using T_INT.
>
> Thanks
> Markus
Markus Grönlund has updated the pull request incrementally with one additional
commit since the last revision:
JVMCI exportation
-
Changes:
- all: https://git.openjdk.org/jdk/pull
On Thu, 22 Aug 2024 09:24:18 GMT, Markus Grönlund wrote:
>> The pattern of the uncommon trap construct was taken from the precedent in
>> LibraryCallKit::inline_profileBoolean().
>
> Is it an implicit invariant that execution always continues in the
> interpreter after
plicit and to access it uniformly from the
> intrinsic code using T_INT.
>
> Thanks
> Markus
Markus Grönlund has updated the pull request incrementally with one additional
commit since the last revision:
Deoptimization::Action_none for no deopt
-
Changes:
- all: https
On Thu, 22 Aug 2024 09:11:03 GMT, Markus Grönlund wrote:
>> The functional requirement I have is that the branch takes an uncommon trap
>> and restarts / re-executes the same method the interpreter, because that
>> version enters the VM where an IllegalStateException is throw
On Thu, 22 Aug 2024 09:09:52 GMT, Markus Grönlund wrote:
>> Right, that would make sense to me because
>> `Deoptimization::Action_reinterpret` might also invalidate the nmethod.
>
> The functional requirement I have is that the branch takes an uncommon trap
> and resta
On Wed, 21 Aug 2024 21:19:03 GMT, Vladimir Kozlov wrote:
>> Greetings,
>>
>> Please help review this change set that implements C2 intrinsics for
>> jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
>>
>> This work is a consequence of
>> [JDK-8338417](https://bugs.o
On Thu, 22 Aug 2024 09:09:15 GMT, Tobias Hartmann wrote:
>> A pin_count overflow/underflow should be a per-thread condition, not global.
>> If there is nothing in the nmethod to be invalidated, maybe this should be
>> `Action_none`?
>
> Right, that would make sense to me because
> `Deoptimiza
Greetings,
Please help review this change set that implements C2 intrinsics for
jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
This work is a consequence of
[JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us
to introduce explicit pin con
rier is impossible because of the event writer.
>
> Therefore, it's imperative to use explicit pin constructs to prevent
> unmounting at this location.
>
> Testing: jdk_jfr
>
> Thanks
> Markus
Markus Grönlund has updated the pull request incrementally with five ad
rier is impossible because of the event writer.
>
> Therefore, it's imperative to use explicit pin constructs to prevent
> unmounting at this location.
>
> Testing: jdk_jfr
>
> Thanks
> Markus
Markus Grönlund has updated the pull request with a new target b
On Wed, 21 Aug 2024 14:21:39 GMT, Markus Grönlund wrote:
>> Thread.currentThread() has an intrinsic, and isVirtual is just a type check.
>> ContinuationSupport.isSupported reads a static final so will disappear once
>> compiled. The pattern we are using in other areas is for
On Thu, 15 Aug 2024 14:32:40 GMT, Alan Bateman wrote:
>> Would it be possible to create a boolean in the EventWriter that indicates
>> if it is associated with a carrier thread or a normal thread (which can
>> never be virtual) and then have two methods.
>>
>> long l = this.carrierThread ?
rier is impossible because of the event writer.
>
> Therefore, it's imperative to use explicit pin constructs to prevent
> unmounting at this location.
>
> Testing: jdk_jfr
>
> Thanks
> Markus
Markus Grönlund has updated the pull request incrementally with on
On Thu, 15 Aug 2024 09:46:04 GMT, Alan Bateman wrote:
>> Good point, thanks.
>
> Yes, it should only unpin if pin completed successfully.
Please see updated changeset.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20588#discussion_r1718203932
rier is impossible because of the event writer.
>
> Therefore, it's imperative to use explicit pin constructs to prevent
> unmounting at this location.
>
> Testing: jdk_jfr
>
> Thanks
> Markus
Markus Grönlund has updated the pull request incrementally with one a
On Thu, 15 Aug 2024 04:11:47 GMT, David Holmes wrote:
>> Greetings,
>>
>> Explicitly pin a virtual thread before acquiring the JFR string pool monitor
>> because migrating a carrier thread local event writer object onto another
>> carrier thread is impossible.
>>
>> During event commit, the t
Greetings,
Explicitly pin a virtual thread before acquiring the JFR string pool monitor
because migrating a carrier thread local event writer object onto another
carrier thread is impossible.
During event commit, the thread is in a critical section because it has loaded
a carrier thread local
On Tue, 7 May 2024 19:32:57 GMT, Erik Gahlin wrote:
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Marked as reviewed by mgronlun (Revi
On Tue, 28 Nov 2023 20:30:52 GMT, Alan Bateman wrote:
> > It would be good to integrate this quite soon because it would release the
> > reliance on ASM and let us only use the new ClassFile API. Now, we need to
> > load both implementations, leading to startup regression.
>
> This is a new ev
On Fri, 17 Nov 2023 16:22:55 GMT, Tim Prinzing wrote:
> Added mirror event with static methods: jdk.internal.event.SelectionEvent
> that provides the duration of select calls and the count of how many keys are
> available.
>
> Emit the event from SelectorImpl::lockAndDoSelect
>
> Test at jdk.
On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin wrote:
>> Could I have a review of a PR that removes the bytecode instrumentation for
>> the exception events.
>>
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> Erik Gahlin has updated the pull request incrementally with one additional
> commit since t
On Mon, 16 Oct 2023 11:28:36 GMT, Erik Gahlin wrote:
>> Hi,
>>
>> Could I have a review of an enhancement that replaces the use of ASM with
>> the new Class-File API. This change only deals with bytecode that writes
>> event data into buffers. Bytecode transformations carried out by classes in
On Fri, 1 Sep 2023 11:26:48 GMT, Alan Bateman wrote:
>> Ok. If the thread can run native code as part of the mount / unmount, and
>> the sampler can see the intermediary state there too, the check is needed.
>
> Thanks. One other thing that I see when more testing with generational ZGC is
> tha
On Wed, 30 Aug 2023 13:56:42 GMT, Alan Bateman wrote:
> In the virtual thread implementation, thread identity switches to the carrier
> before freezing and switches back to the virtual thread after thawing. This
> was a forced move due to issues getting JVMTI to work with virtual threads.
> JV
On Thu, 31 Aug 2023 19:28:50 GMT, Alan Bateman wrote:
>> There are some native methods that we execute during mount/unmount
>> transitions. From what I see they all seem to be defined as
>> `@IntrinsicCandidate`, but if for some reason we don't execute the intrinsic
>> version (interp only mod
On Thu, 31 Aug 2023 11:41:03 GMT, Alan Bateman wrote:
>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 410:
>>
>>> 408: }
>>> 409: if (JAVA_SAMPLE == type) {
>>> 410: if (thread_state_in_java(thread) &&
>>> !is_vthread_in_transition(thread)) {
>>
>> I think this che
On Wed, 30 Aug 2023 13:56:42 GMT, Alan Bateman wrote:
> In the virtual thread implementation, thread identity switches to the carrier
> before freezing and switches back to the virtual thread after thawing. This
> was a forced move due to issues getting JVMTI to work with virtual threads.
> JV
On Tue, 8 Nov 2022 12:03:06 GMT, Erik Gahlin wrote:
> Could I have a review of PR that fixes so unsigned numbers are printed
> correctly in the jfr tool.
>
> Testing:
> test/jdk/jdk/jfr
> test/jdk/jdk/security/logging/
>
> Thanks
> Erik
Marked as reviewed by mgronlun (Reviewer).
41 matches
Mail list logo
