[GR-44559] Finish ThreadMXBean implementation for Native Image. #7945

smthelusive · 2023-12-04T10:30:28Z

The functionality of ThreadMXBean is implemented and working within native image GR-44559

Testing

Build native image with: --enable-monitoring=jmxserver,jvmstat
Run it with:
-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=9996 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.enableThreadContentionMonitoring=true

Tools like VisualVM show the Thread monitoring info:

Example result of dumpAllThreads method call:

Result of getThreadInfo by Thread id (the locks and monitors shouldn't be included):

Deadlock detection returns an array of ids of deadlocked threads:

Closes #6101

oracle-contributor-agreement · 2023-12-04T10:30:34Z

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

PR author: smthelusive
[email protected] (@smthelusive)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

oracle-contributor-agreement · 2023-12-04T16:02:59Z

Thank you for signing the OCA.

roberttoyonaga · 2023-12-08T20:19:58Z

Haven't look at this in detail yet, but full support for ThreadMXBean would be very nice to have!

You may need to run mx eclipseformat for that failing gate to pass.

smthelusive · 2023-12-08T23:14:52Z

Thank you for the tip @roberttoyonaga! Done 👍

roberttoyonaga

Hi @smthelusive ! It would be very nice to have this ThreadMXBean support. I left some comments/concerns below.

roberttoyonaga · 2023-12-12T18:32:21Z

substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/ThreadMXUtils.java

+    public static class ThreadInfoConstructionUtils {
+
+        private static StackTraceElement[] getStackTrace(Thread thread, int maxDepth) {
+            return maxDepth == -1 || maxDepth >= thread.getStackTrace().length ? thread.getStackTrace() : Arrays.copyOfRange(thread.getStackTrace(), 0, maxDepth);


Since the thread handling the ThreadMXBean call is likely not the thread we're getting the stacktrace for, calling thread.getStackTrace() will result in a safepoint operation in order to do the stack walk. So to reduce pause time, I think we should avoid calling thread.getStackTrace() twice in this method.

roberttoyonaga · 2023-12-12T18:50:47Z

substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/ThreadMXUtils.java

+        private static int getThreadState(Thread thread) {
+            int state = PlatformThreads.getThreadStatus(thread);
+            boolean inNative = VMThreads.StatusSupport
+                            .getStatusVolatile(PlatformThreads.getIsolateThreadUnsafe(thread)) == VMThreads.StatusSupport.STATUS_IN_NATIVE;


I'm not sure it's safe here to use the isolate thread (which may not be the current thread) without first holding the VMThreads#THREAD_MUTEX or being in a VM operation. This is because getStatusVolatile reads the thread local StatusSupport#statusTL. I think it's possible for the isolate thread we're dealing with to go away unexpectedly, which would result in illegally accessing that thread local. @christianhaeubl can you confirm this?

roberttoyonaga · 2023-12-12T20:15:39Z

...evm/src/com.oracle.svm.core/src/com/oracle/svm/core/monitor/MultiThreadedMonitorSupport.java

@@ -248,6 +248,9 @@ public void monitorEnter(Object obj, MonitorInflationCause cause) {
                if (monitor == null) { // successful
                    JavaMonitorInflateEvent.emit(obj, startTicks, MonitorInflationCause.MONITOR_ENTER);
                    newMonitor.latestJfrTid = current;
+                    JavaThreads.JMXMonitoring.addThreadMonitor(newMonitor);
+                    newMonitor.blockedObject = obj;
+                    newMonitor.depth = Thread.currentThread().getStackTrace().length;
                    return;


Based on the docs here it seems like blockObject and ownerThread should only be set when the thread is actually blocked and unable to enter the critical section. So, I don't think the instrumentation here is correct since this is the monitor enter fast path.

Additionally, the instrumentation needs to be added for the slow path as well (when there actually is contention).

Hi @roberttoyonaga! Thank you for reviewing my PR.

Let me clarify on this section a bit. I'm not actually setting a thread blocker here. It's been handled before me, and in the end I'm getting the blocker by reading Thread.parkBlocker field.
The problem is that when the thread is blocked upon a monitor, that field will contain an instance of JavaMonitor. JavaMonitor represents the monitor, but does not save any information about the original Object with that blocked monitor, so I need to save it when the new JavaMonitor is created.

I see that I did miss some things:

I do it in fast path where we're creating a new JavaMonitor, however I'm not handling the use-case when we're creating new monitor for additionalMonitors, so I'll make a change;

No need to set the blockedObject to null on monitorExit later in this class;

I need to update the depth when re-entering the same monitor, and also on monitorExit when monitor.acquisitions > 1.

Please let me know if that makes sense.

Ok I see. So you only ever need to write blockedObject upon monitor inflation. And you're relying on LockSupport.getBlocker to get the status of the thread before reading that field.

Yes, exactly 👍

roberttoyonaga · 2023-12-12T21:01:19Z

...com/oracle/svm/core/locks/Target_java_util_concurrent_locks_AbstractOwnableSynchronizer.java

+ */
+@SuppressWarnings({"unused"})
+@TargetClass(className = "java.util.concurrent.locks.AbstractOwnableSynchronizer", onlyWith = JmxIncluded.class)
+@Substitute()


nitpick. I think you don't really have to substitute the whole class here. You could try just substituting setExclusiveOwnerThread (you may need to alias the exclusiveOwnerThread field)

roberttoyonaga · 2023-12-12T21:21:27Z

...evm/src/com.oracle.svm.core/src/com/oracle/svm/core/monitor/MultiThreadedMonitorSupport.java

@@ -306,6 +309,11 @@ public void monitorExit(Object obj, MonitorInflationCause cause) {
            monitor = getOrCreateMonitor(obj, cause);
        }
        monitor.monitorExit();
+        if (monitor.acquisitions == 1) {
+            monitor.blockedObject = null;


Does the thread still qualify as "blocked" when it is no longer waiting and enters the critical section? If not, then maybe this deaccounting should be moved to the end of JavaMonitor#monitorEnter?

roberttoyonaga · 2023-12-12T21:46:59Z

substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/ThreadMXUtils.java

+            Object[] monitorObjects = new Object[monitors != null ? monitors.size() : 0];
+            int[] monitorDepths = new int[monitorObjects.length];
+            for (int i = 0; i < monitorObjects.length; i++) {
+                JavaMonitor javaMonitor = monitors.iterator().next();


Is it thread-safe to be iterating the monitors without synchronization? The target thread can be running and its set of monitors may change while we are in this method.

For example, what if monitors has size 10 at line 95, then by the time we reach line 97 monitors has size 5. Then monitorObjects.length != monitors.size().

roberttoyonaga · 2023-12-12T21:50:44Z

substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/ThreadMXUtils.java

+            return new Blocker(blocker, null);
+        }
+
+        private static Object[] getLockedSynchronizers(Thread thread) {


Same concern in this method as in getLockedMonitors

fniephaus

Thanks a lot for this PR, well done @smthelusive!
Since threading is rather important, the PR will need to be reviewed carefully. Please feel free to reach out if you have any questions or in case the PR (or you) get stuck. 😉

I'm going to run our internal gates on this. I will report any issues here...

fniephaus · 2023-12-19T09:55:58Z

.../com.oracle.svm.core/src/com/oracle/svm/core/jdk/Target_java_lang_management_ThreadInfo.java

@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2017, 2023, Oracle and/or its affiliates. All rights reserved.


Please update all years in copyright headers in files that you are adding. They should refer to the actual year(s). Since it's unlikely that this will still be merged this year (we are getting close to the Xmas break), I think you can just use this already:

Suggested change

* Copyright (c) 2017, 2023, Oracle and/or its affiliates. All rights reserved.

* Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved.

fniephaus · 2023-12-19T10:03:07Z

substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/ThreadMXUtils.java

+        private static final HashSet<Long> deadlocked = new HashSet<>();
+        private static final HashSet<Long> chain = new HashSet<>();
+        private static ThreadInfo[] allThreadInfos = new ThreadInfo[0];


Is this global state really needed? Could you allocate the objects in findDeadlockedThreads and pass them to the other private helpers instead?

fniephaus · 2023-12-19T10:05:46Z

...vm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/management/SubstrateThreadMXBean.java

    }

    @Override
    public ThreadInfo[] getThreadInfo(long[] ids) {
-        return new ThreadInfo[0];
+        return (ThreadInfo[]) Arrays.stream(ids).mapToObj(this::getThreadInfo).toArray();


Can you re-use getThreadInfo(long[] ids, int maxDepth) here?

Suggested change

return (ThreadInfo[]) Arrays.stream(ids).mapToObj(this::getThreadInfo).toArray();

return getThreadInfo(ids, -1);

fniephaus · 2023-12-19T12:34:58Z

Here's a ClassCastException I ran into testing this:

java.lang.ClassCastException: java.util.concurrent.locks.ReentrantLock$NonfairSync cannot be cast to com.oracle.svm.core.locks.Target_java_util_concurrent_locks_AbstractOwnableSynchronizer
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.ThreadMXUtils.toTarget(ThreadMXUtils.java:56)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.ThreadMXUtils$ThreadInfoConstructionUtils.getBlockerInfo(ThreadMXUtils.java:87)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.ThreadMXUtils$ThreadInfoConstructionUtils.getThreadInfo(ThreadMXUtils.java:119)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.management.SubstrateThreadMXBean.getThreadInfo(SubstrateThreadMXBean.java:188)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.management.SubstrateThreadMXBean.lambda$getThreadInfo$2(SubstrateThreadMXBean.java:299)
	at [email protected]/java.util.stream.LongPipeline$1$1.accept(LongPipeline.java:177)
	at [email protected]/java.util.Spliterators$LongArraySpliterator.forEachRemaining(Spliterators.java:1223)
	at [email protected]/java.util.Spliterator$OfLong.forEachRemaining(Spliterator.java:777)
	at [email protected]/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at [email protected]/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at [email protected]/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
	at [email protected]/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
	at [email protected]/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.management.SubstrateThreadMXBean.getThreadInfo(SubstrateThreadMXBean.java:300)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.management.SubstrateThreadMXBean.dumpAllThreads(SubstrateThreadMXBean.java:305)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.management.SubstrateThreadMXBean.findDeadlockedThreads(SubstrateThreadMXBean.java:283)

smthelusive · 2023-12-20T21:10:45Z

Hi @fniephaus and @roberttoyonaga. Thank you both for the review! I've fixed the points that you mentioned and reworked some parts.

Here is what changed:

Fix calling Thread.getStackTrace multiple times.
Change the way to detect if the thread is running native code. StackTraceElement contains information whether the method is a native method. IsolateThread isn't necessary for this approach, which is nice.
Optimise SubstrateThreadMXBean.dumpAllThreads flow, so it doesn't look up all threads twice.
Reuse getThreadInfo(long[] ids, int maxDepth) as suggested.
Collect monitor re-enters as stack. While testing without native image, I noticed that on monitor re-enter in the same Thread the Object is stored multiple times as a locked monitor, each time with different depth. So I changed the implementation and this also resulted in storing the depths properly.
Handle all cases when JavaMonitor is created or reentered. This includes also handling the MultiThreadedMonitorSupport.additionalMonitors use-case for the objects that don't have the monitor offset.
Not substitute the whole AbstractOwnableSynchronizer class.
Lock monitors and locks when reading these collections and make that piece of code more reliable.
Solve the problem with the stack frame offset when the monitor is entered. The problem: I want to know where in the stack the monitor was actually obtained in the user code. However, while handling the monitor creation, we are putting several extra frames on top of the stack and then remove them, so they are not in the stack at the moment when we're reporting anything. It is possible to detect where exactly the monitor actually happened by checking how many top frames have module/class names of our internal code, but it's expensive. A lot cheaper is to have a fixed offset, especially since it's a single use-case with the same flow, where we always have exactly 4 extra frames on the stack… I'm not a big fan of this solution, but couldn't come up with a better one.
Simplified deadlock detection logic.
Fixed the years in the headers.
@fniephaus I couldn't reproduce the ClassCastException, but my changes should have fixed the potential of it happening. Could you please check?

Let me know if you have more suggestions, I will do my best to fix it. :)

roberttoyonaga

Happy new year @smthelusive! Thank you for the changes. You've addressed most of my previous questions/concerns. I have left a few more below.

roberttoyonaga · 2024-01-02T15:25:55Z

substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/thread/JavaThreads.java

+                 * synchronized block occurred.
+                 */
+                int stackSizeWithoutInternalLogic = -1;
+                if (MonitorInflationCause.MONITOR_ENTER.equals(cause)) {


Yes in openJDK, VM level frames get skipped, but not in SubstrateVM. JFR has the same issue. I don't know if hard-coding the frame skip-count is the best solution since it will require remembering to do maintenance whenever the monitor enter / stackwalking implementation is changed. Personally, I think checking the module/package names is better (but others may disagree).

I think we should at least add a comment to explicitly specify that the hardcoded value needs to be updated whenever the implementation changes.

Also, what about other inflation causes? Isn't it always the case that we'll need to remove some internal frames from the stacktrace?

I've made a change to check the module names instead.

Thanks. This seems better now.

roberttoyonaga · 2024-01-02T15:33:31Z

substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/ThreadMXUtils.java

+            if (monitors != null) {
+                synchronized (monitors) {
+                    Object[] monitorObjects = monitors.stream().map(JMXMonitoring.MonitorInfo::originalObject).toArray();
+                    int[] monitorDepths = monitors.stream().mapToInt(monitorInfo -> stacktraceLength < 0 ? -1 : stacktraceLength - monitorInfo.stacksize()).toArray();


Why do you do the subtraction stacktraceLength - monitorInfo.stacksize()? Shouldn't the stackdepth only be monitorInfo.stacksize() (since you already substracted the internal frames in addThreadMonitor)?

Hi @roberttoyonaga, happy new year! Thank you for your review. I will look into the comments and make the changes.
For this one, I made a drawing to illustrate what I'm doing here:

roberttoyonaga · 2024-01-02T16:14:42Z

substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/ThreadMXUtils.java

+        private static LockedMonitors getLockedMonitors(Thread thread, int stacktraceLength) {
+            ArrayDeque<JMXMonitoring.MonitorInfo> monitors = JMXMonitoring.getThreadMonitors(thread);
+            if (monitors != null) {
+                synchronized (monitors) {


I believe there is still a race here. I don't think it's enough to only synchronize here when we're reading the monitors. We also need to synchronize when we modify the stack of monitors in removeThreadMonitor and addThreadMonitor. For example, if monitors is modified in between when monitorObjects and monitorDepths is assigned, monitorObjects and monitorDepths won't be the same size.

Hi @roberttoyonaga, I see.
So, only the thread that owns the monitors is modifying the monitors collection. The other thread is reading it here. I have made a change to get an unmodifiable copy of the monitors list, so then I can use it without worrying about changes in the original monitors collection. I think I shouldn't block the writes when I'm reading the collection.

Thank you. I think this idea of getting a "snapshot" of the list is good. However, there is still the possibility that the list is modified while List.copyOf() is in-progress (race during construction). I'm not sure how bad this could be because it depends on the implementation of List.copyOf() , ArrayDeque.push ArrayDeque.pop

roberttoyonaga · 2024-01-02T16:20:16Z

substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/ThreadMXUtils.java

+        private static Object[] getLockedSynchronizers(Thread thread) {
+            EconomicSet<AbstractOwnableSynchronizer> locks = JMXMonitoring.getThreadLocks(thread);
+            if (locks != null) {
+                synchronized (locks) {


I believe there is still a race here. I don't think it's enough to only synchronize here when we're reading the locks. We also need to synchronize when we modify the set of locks . For example, if the set of locks is modified by the target thread in between when we assign lockObjects a size and when we finish iterating the set, then we may try to access an index that doesn't exist.

Hi @roberttoyonaga, indeed there was such possibility.
So, only one thread is adding or removing locks - it's the thread that owns them. Another thread is reading these values for reporting here. I did a small change here to use an iterator over the locks. This way I'm sure that any modifications of the underlying collection won't affect me when I'm reading the collection (and I think I shouldn't block the writes while reading it).

This is better than before, but doesn't prevent the race. While iterating the list here, the owning thread may concurrently remove items from the list. Will this cause problems?

Hi @roberttoyonaga,
when the values get removed, they are set to null (in an array), and on iterating, the null values are skipped. However, there might be a problem when the size shrinks, if that happens in between hasNext() and next() calls.
I've made a change. It's really convenient to continue using the EconomicSet since I can provide it with equivalence strategy that uses System.identityHashCode. So I decided to go for external synchronization. I'm not using the ReadWriteLock here because that adds an extra lock that the thread obtains while it's already busy adding a lock, so it will loop trying to add more lock entries. So the monitor it is.

I've also made a change for the monitors collection, where I'm using now ConcurrentLinkedDeque.

So the monitor it is

I think your new approach has solved the concurrency problem here. However, I think it's possible to easily optimize this with more fine-grained locking. You could maybe synchronize on the lock collection itself (Target_java_lang_Thread#locks) so multiple threads can work simultaneously on different collections. Is there a reason you are using a global lock instead?

I've also made a change for the monitors collection, where I'm using now ConcurrentLinkedDeque.

What is the purpose of this change? Changing to a ConcurrentLinkedDeque does not make the construction of the list copy atomic (return List.copyOf(targetThread.monitors);). So I still have the same comment as before.

Indeed, I shouldn't be using the global lock. Fixed that.

Regarding the ConcurrentLinkedDeque, I should have used the Iterator that it provides instead of List.copyOf. According to the documentation, this Iterator is weakly consistent:

they may proceed concurrently with other operations

they will never throw ConcurrentModificationException

they are guaranteed to traverse elements as they existed upon construction exactly once, and may (but are not guaranteed to) reflect any modifications subsequent to construction.

Thank you! Both concerns are resolved now.

roberttoyonaga · 2024-01-26T20:46:20Z

substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/thread/JavaThreads.java

+        private static void setThreadBlockedToEnterLock(Target_java_lang_Thread thread) {
+            if (thread.lastStartedBlocked == NO_VALUE) {
+                thread.lastStartedBlocked = System.currentTimeMillis();
+                thread.blockedCount++;


Are we guaranteed to always be dealing with the current thread? If so, maybe it's worth adding an assertion here.

Otherwise, is it safe to be un-atomically modifying thread.lastStartedBlocked, thread.blockedCount, thread.waitedCount, etc ? Or do we require synchronization here as well? Or do you assume it's safe since we just started waiting/blocking?

For the thread states that I'm interested in, it's modified by the current thread only.
However, there are use-cases such as when a new thread is initialized, then its state can be set by its parent just before the new thread is assigned as current. In this case, the thread state will be set to NEW, and I'm not updating anything for this state.

roberttoyonaga

Thank you for working on this @smthelusive! These changes look good to me now.

It would be nice to also have some tests for this MXBean in the future as well.

roberttoyonaga · 2024-02-08T13:56:49Z

...com/oracle/svm/core/locks/Target_java_util_concurrent_locks_AbstractOwnableSynchronizer.java

+ * the locks per thread when JMX support is enabled.
+ */
+@SuppressWarnings({"unused"})
+@TargetClass(value = java.util.concurrent.locks.AbstractOwnableSynchronizer.class, onlyWith = JmxIncluded.class)


One last minor comment. I've poorly named this:JmxIncluded is based on whether remote JMX support is included. I think we want to have this substitution even if remote JMX is excluded because we can still use the MBeanServer locally.

smthelusive · 2024-02-22T09:18:06Z

Hi @fniephaus and @christianhaeubl!
It looks like I need some more reviews for this PR, all the previous concerns were addressed 😊
Please let me know if you have any other comments, I will be happy to fix it.
Thank you!

fniephaus · 2024-02-22T11:19:06Z

Hey @smthelusive, thanks for the update! I'm going to run the public and internal gates on your PR again. Hopefully, we soon have enough time to review your PR as well. We are currently busy integrating other contributions from @roberttoyonaga and others.

fniephaus · 2024-02-22T11:31:39Z

This PR unfortunately got mirrored to #8430, sorry about that. I am adding fixes for the style gate so that other gates can run as well.

fniephaus · 2024-02-22T13:49:51Z

Looks like our internal gate has found a problem with the PR:

Fatal error: java.lang.AssertionError: null
    at com.oracle.svm.core.thread.JavaThreads$JMXMonitoring.addThreadLock(JavaThreads.java:532)
    at java.util.concurrent.locks.AbstractOwnableSynchronizer.setExclusiveOwnerThread(AbstractOwnableSynchronizer.java:62)
    at java.util.concurrent.locks.ReentrantLock$NonfairSync.initialTryLock(ReentrantLock.java:226)
    at java.util.concurrent.locks.ReentrantLock$Sync.lock(ReentrantLock.java:152)
    at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:322)
    at jdk.internal.misc.InternalLock.lock(InternalLock.java:74)
    at java.io.PrintStream.write(PrintStream.java:788)
    at java.io.PrintStream.print(PrintStream.java:1002)
    at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:697)
    at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:690)
    at java.lang.Thread.dispatchUncaughtException(Thread.java:2901)
    at java.lang.VirtualThread.run(VirtualThread.java:311)
    at java.lang.VirtualThread$VThreadContinuation$1.run(VirtualThread.java:190)

This suggests that the implementation may not be working correctly with virtual threads. Could you take a look, please?

smthelusive · 2024-04-26T14:05:26Z

Hi all, thank you for your reviews.
Given the latest feedback in the mirror PR I don't think that I can proceed with the current solution, hence closing this PR.
Thank you for your time, your help, and this opportunity to learn.

oracle-contributor-agreement bot added the OCA Required At least one contributor does not have an approved Oracle Contributor Agreement. label Dec 4, 2023

smthelusive force-pushed the jmx-thread-support branch from 565eed1 to 8da4ed7 Compare December 4, 2023 14:35

oracle-contributor-agreement bot added OCA Verified All contributors have signed the Oracle Contributor Agreement. and removed OCA Required At least one contributor does not have an approved Oracle Contributor Agreement. labels Dec 4, 2023

smthelusive mentioned this pull request Dec 4, 2023

[GR-44559] Finish ThreadMXBean implementation for Native Image. #6101

Open

fniephaus requested review from christianhaeubl and fniephaus December 5, 2023 05:11

fniephaus requested a review from roberttoyonaga December 8, 2023 21:40

smthelusive force-pushed the jmx-thread-support branch from 8da4ed7 to 21d598c Compare December 8, 2023 23:07

smthelusive force-pushed the jmx-thread-support branch from 21d598c to 984c3c2 Compare December 13, 2023 13:35

roberttoyonaga suggested changes Dec 13, 2023

View reviewed changes

fniephaus reviewed Dec 19, 2023

View reviewed changes

smthelusive force-pushed the jmx-thread-support branch from 984c3c2 to e7cd052 Compare December 20, 2023 21:02

smthelusive force-pushed the jmx-thread-support branch from e7cd052 to 0177e46 Compare December 20, 2023 21:15

roberttoyonaga reviewed Jan 2, 2024

View reviewed changes

fniephaus assigned fniephaus and smthelusive Jan 3, 2024

smthelusive force-pushed the jmx-thread-support branch 2 times, most recently from 75984b5 to 5397a4d Compare January 26, 2024 19:29

roberttoyonaga reviewed Jan 26, 2024

View reviewed changes

smthelusive force-pushed the jmx-thread-support branch 2 times, most recently from d50524d to f447bc2 Compare February 5, 2024 13:23

roberttoyonaga approved these changes Feb 7, 2024

View reviewed changes

smthelusive force-pushed the jmx-thread-support branch from f447bc2 to 7e5ae47 Compare February 7, 2024 23:19

roberttoyonaga reviewed Feb 8, 2024

View reviewed changes

[GR-44559] Finish ThreadMXBean implementation for Native Image.

a6ed7e9

smthelusive force-pushed the jmx-thread-support branch from 7e5ae47 to a6ed7e9 Compare February 8, 2024 15:24

fniephaus mentioned this pull request Feb 22, 2024

[GR-44559] Finish ThreadMXBean implementation for Native Image. #8430

Open

smthelusive closed this Apr 26, 2024

		@@ -0,0 +1,43 @@
		/*
		* Copyright (c) 2017, 2023, Oracle and/or its affiliates. All rights reserved.

	* Copyright (c) 2017, 2023, Oracle and/or its affiliates. All rights reserved.
	* Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved.

	return (ThreadInfo[]) Arrays.stream(ids).mapToObj(this::getThreadInfo).toArray();
	return getThreadInfo(ids, -1);

[GR-44559] Finish ThreadMXBean implementation for Native Image. #7945

[GR-44559] Finish ThreadMXBean implementation for Native Image. #7945

Conversation

smthelusive commented Dec 4, 2023 • edited by fniephaus Loading

Testing

oracle-contributor-agreement bot commented Dec 4, 2023

oracle-contributor-agreement bot commented Dec 4, 2023

roberttoyonaga commented Dec 8, 2023

smthelusive commented Dec 8, 2023

roberttoyonaga left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fniephaus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fniephaus commented Dec 19, 2023

smthelusive commented Dec 20, 2023

roberttoyonaga left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

roberttoyonaga Jan 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

roberttoyonaga Jan 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

roberttoyonaga left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smthelusive commented Feb 22, 2024

fniephaus commented Feb 22, 2024

fniephaus commented Feb 22, 2024

fniephaus commented Feb 22, 2024

smthelusive commented Apr 26, 2024

smthelusive commented Dec 4, 2023 •

edited by fniephaus

Loading

roberttoyonaga Jan 26, 2024 •

edited

Loading

roberttoyonaga Jan 26, 2024 •

edited

Loading