Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8286830: ~HandshakeState should not touch oops #8795

Closed
wants to merge 1 commit into from

Conversation

pchilano
Copy link
Contributor

@pchilano pchilano commented May 19, 2022

On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden.
To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things:

  • Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state.
  • Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true.

I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases.

I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that.

Thanks,
Patricio


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/8795/head:pull/8795
$ git checkout pull/8795

Update a local copy of the PR:
$ git checkout pull/8795
$ git pull https://git.openjdk.java.net/jdk pull/8795/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 8795

View PR using the GUI difftool:
$ git pr show -t 8795

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/8795.diff

@bridgekeeper
Copy link

bridgekeeper bot commented May 19, 2022

👋 Welcome back pchilanomate! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented May 19, 2022

@pchilano The following label will be automatically applied to this pull request:

  • hotspot-runtime

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the hotspot-runtime label May 19, 2022
@pchilano pchilano marked this pull request as ready for review May 19, 2022
@openjdk openjdk bot added the rfr label May 19, 2022
@mlbridge
Copy link

mlbridge bot commented May 19, 2022

Webrevs

// Since we are in thread_in_vm state and suspension is done with handshakes,
// we can just put in the exiting state and it will be correctly handled.
// Also, no more async exceptions will be added to the queue after this point.
set_terminated(_thread_exiting);
Copy link
Member

@dholmes-ora dholmes-ora May 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have expected that cleaning up any async exceptions has to happen after we set the _thread_exiting state; otherwise what happens if another thread is trying to install an async exception on the current thread before we set it?

Copy link
Contributor Author

@pchilano pchilano May 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ordering of cleaning up the async exceptions in the queue and the write of _thread_exiting doesn't really matter as long as the state remains _thread_in_vm. We install async exceptions inside a synchronous handshake, which can only happen while the target is handshake/safepoint safe. Since moving to a safe state by the target and reading of the state by the handshaker uses acquire/release semantics, the handshaker will already see the _thread_exiting value inside the handshake.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Hi Patricio,

I still need to find time to look at this in more detail. Things are definitely on the right track but I want to check the details. I still think we should be able to have a simple scheme whereby once the thread is marked as _thread_exiting then it can't engage in further handshakes and so at that point we could explicitly destroy the HandshakeState rather than special casing async exceptions.

I'd also like for Dan to see this and he is still away for a while unfortunately.

Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true.

Why do you think this is necessary? I'm not saying it is incorrect but I'm not sure it is necessary either and the less the termination sequence is perturbed the better.

Thanks.

@pchilano
Copy link
Contributor Author

pchilano commented May 20, 2022

Hi David,

Thanks for taking a look at this.

I still need to find time to look at this in more detail. Things are definitely on the right track but I want to check the details. I still think we should be able to have a simple scheme whereby once the thread is marked as _thread_exiting then it can't engage in further handshakes and so at that point we could explicitly destroy the HandshakeState rather than special casing async exceptions.

If by "can't engage in further handshakes" you mean to make sure no other handshake closure could be executed against it after moving to _thread_exiting, then yes we can do that. But the queue is lock free for inserts so there could still be some handshaker trying to add an operation to the queue after that, although the closure just won't be executed. That means we know no other ThreadSelfSuspensionHandshake or AsyncExceptionHandshake operation will be added to the queue after _thread_exiting, since those happen inside the closure of a synchronous handshake. But there could still be synchronous operations remaining or about to be added to the queue, again eventhough the closures won't be executed. In fact we could have some other async operation added to the queue after that since they don't necessarily need to be added inside another handshake, but we don't have any of those today.

I'd also like for Dan to see this and he is still away for a while unfortunately.

Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true.

Why do you think this is necessary? I'm not saying it is incorrect but I'm not sure it is necessary either and the less the termination sequence is perturbed the better.

We need to guarantee that after the async exception cleanup no other async exception can be installed. The key for that is the is_exiting() check I added in install_async_exception(). But for the destroy_vm=true path case we never set it, so if the exiting thread blocks while trying to acquire the Threads_lock in Threads::remove() for example, we could have a new handshake that installs an async exception. Later in Threads::destroy_vm() we would hit this same issue of touching an oop when doing "delete thread".

@dholmes-ora
Copy link
Member

dholmes-ora commented May 23, 2022

But there could still be synchronous operations remaining or about to be added to the queue, again even though the closures won't be executed. In fact we could have some other async operation added to the queue after that

Sorry I'm not clear on the exact details. But a handshake requires the target thread to respond to the handshake request (that is afterall the "handshake" part of it). Once a thread starts to exit it will/should no longer respond to any handshake requests (sync or async) so the submitter of such a request must be polling for the target thread to either acknowledge the handshake or else indicate it is exiting; if the latter then the submitter abandons the handshake request because the target is considered dead. Are you saying that the submitter actually installs the op in the target's queue even if never acknowledged by the target (due to it exiting)?

@pchilano
Copy link
Contributor Author

pchilano commented May 23, 2022

But there could still be synchronous operations remaining or about to be added to the queue, again even though the closures won't be executed. In fact we could have some other async operation added to the queue after that

Sorry I'm not clear on the exact details. But a handshake requires the target thread to respond to the handshake request (that is afterall the "handshake" part of it). Once a thread starts to exit it will/should no longer respond to any handshake requests (sync or async) so the submitter of such a request must be polling for the target thread to either acknowledge the handshake or else indicate it is exiting; if the latter then the submitter abandons the handshake request because the target is considered dead. Are you saying that the submitter actually installs the op in the target's queue even if never acknowledged by the target (due to it exiting)?

Yes, the handshaker just checks if the target is included in the thread list it created. If it is included, it adds the operation to the queue. Then it will loop calling HandshakeState::try_process() until the operation is processed(which doesn't mean the closure will actually be executed). So until the target removes itself form the active threads list new operations could be added to the queue. If we want to avoid that and check the terminated status too then we would need to add extra locking to the add operation, but I don't think that's what we want.

@dholmes-ora
Copy link
Member

dholmes-ora commented May 26, 2022

Hi Patricio,

I've had a much closer look at the details and have been surprised at how "loose" the coordination between handshakes and thread termination actually is. It would be good, IMO, if there was a point (like setting is_exiting) where you knew that once that was reached a thread would have zero interaction with handshakes and could delete everything handshake related if you wanted to.

The fact that the acquisition of the Threads_lock in Threads::remove might process any handshake certainly complicates things. I think, at a minimum, it would be preferable if we actually checked _is_exiting in that polling/checking logic so that we knew no further handshakes could be executed once _is_exiting is true - rather than placing the check in the operation (e.g. in install_async_exception()). That still relies on your changes for the destroy_vm case of course.

So future RFE's aside everything you are doing seems fine and reasonable. Thanks for your patience walking me through this one.

@openjdk
Copy link

openjdk bot commented May 26, 2022

@pchilano This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8286830: ~HandshakeState should not touch oops

Reviewed-by: dholmes, rehn

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 174 new commits pushed to the master branch:

  • d833173: 8286711: AArch64: serviceability agent tests fail with PAC enabled
  • 19fb8ab: 8287195: AArch64: Client VM build failure after JDK-8283689
  • 1b9987c: 8287288: Fix some typos in C1
  • 447ae00: 8287418: riscv: Fix correctness issue of MacroAssembler::movptr
  • a27ba1a: 8287363: null pointer should use NULL instead of 0
  • 744b822: 8287073: NPE from CgroupV2Subsystem.getInstance()
  • 5848a60: 8286093: java/awt/geom/Path2D/UnitTest.java failed with "RuntimeException: 2D bounds too small"
  • 3d2d039: 8287440: Typo in package-info.java of java.util.random
  • 36350bf: 8287484: JFR: Seal RecordedObject
  • a6e2e22: 8285008: JFR: jdk/jfr/jmx/streaming/TestClose.java failed with "Exception: Expected repository to be empty"
  • ... and 164 more: https://git.openjdk.java.net/jdk/compare/5bea46110c3ec9c6c17c00b13d1578cb2981ce51...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label May 26, 2022
@pchilano
Copy link
Contributor Author

pchilano commented May 26, 2022

Hi Patricio,

I've had a much closer look at the details and have been surprised at how "loose" the coordination between handshakes and thread termination actually is. It would be good, IMO, if there was a point (like setting is_exiting) where you knew that once that was reached a thread would have zero interaction with handshakes and could delete everything handshake related if you wanted to.

The fact that the acquisition of the Threads_lock in Threads::remove might process any handshake certainly complicates things. I think, at a minimum, it would be preferable if we actually checked _is_exiting in that polling/checking logic so that we knew no further handshakes could be executed once _is_exiting is true - rather than placing the check in the operation (e.g. in install_async_exception()). That still relies on your changes for the destroy_vm case of course.

So future RFE's aside everything you are doing seems fine and reasonable. Thanks for your patience walking me through this one.

Thanks for the review David! I'll make sure to wait until Dan comes back next week before integrating since he might also want to take a look.

robehn
robehn approved these changes May 30, 2022
Copy link
Contributor

@robehn robehn left a comment

@dholmes-ora originally the idea was that if a JT is on a ThreadsList it will respond to handshakes. Note that while on the ThreadsList it may participate in safepoints.
Since we also touch oops after "thread is exiting" we cannot stop responding to handshake after this stage. (ensure_join)

At one point I actually had a patch which removed the terminated state all together, and instead used on or off ThreadsList, which I think is the right approach, reducing complexity.

Anyhow a way longer discussion, this seems fine for now @pchilano , thanks!

@dholmes-ora
Copy link
Member

dholmes-ora commented May 30, 2022

@robehn Using on/off the ThreadsList does not seem right to me. Removal from the main thread-list happens much later than the point at which handshaking a terminating thread makes no sense; and removal from all threads-lists may not occur under we get into ThreadSMR::delete. To me it makes perfect sense for a thread to have a terminating state, like is_exiting, which effectively hides it from the rest of the VM in terms of interacting with it. To all and intents and purposes such a thread has already terminated as far as most of the outside world is concerned.

@robehn
Copy link
Contributor

robehn commented May 30, 2022

@robehn Using on/off the ThreadsList does not seem right to me. Removal from the main thread-list happens much later than the point at which handshaking a terminating thread makes no sense; and removal from all threads-lists may not occur under we get into ThreadSMR::delete. To me it makes perfect sense for a thread to have a terminating state, like is_exiting, which effectively hides it from the rest of the VM in terms of interacting with it. To all and intents and purposes such a thread has already terminated as far as most of the outside world is concerned.

The state which hides it from the rest of the VM is the removal from the ThreadsList.
Since the JT after the state "is_exiting" still uses oops and interacts with Java, it's no where close to be hidden.
It participates in safepoint, still does JVM TI callbacks, it generates JFR events, etc.. (I guess posting contended monitor enter after posting thread end is a bug).
Basically the only subsystem that care about terminated flag is JVM TI and other 'serviceability'.
You can see the comment: "These things needs to be done while we are still a Java Thread"
And while we are a JavaThread we must participate in safepoints and handshakes.

@dholmes-ora
Copy link
Member

dholmes-ora commented May 30, 2022

Since the JT after the state "is_exiting" still uses oops and interacts with Java, it's no where close to be hidden.

Setting is_exiting is the start of hiding the thread from the rest of the system. The only interaction with "Java" after that is ensure_join to perform the ObjectMonitor notification and to mark the Thread's own Java state as "dead". This is the point at which this thread is dead to Java code and thus "hidden". The is_exiting state should be a gate for any JVMTI callbacks and JFR events as they don't apply to "terminated" threads - for JFR we call on_thread_exit shortly after setting the is_exiting state and just before that we could still post monitor exit events).

The thread must participate in safepoints up until its last oop-touch, which means after barrier_set->on_thread_detach() it does not need to participate in safepoints - and shouldn't hit any more polling points after that anyway.

A handshake with a thread is only needed to interact with that thread in some way and we don't interact with "terminated" threads - so no handshakes needed.

We have a two-stage termination sequence (is_exiting then terminated) precisely because the vast majority of interactions with a thread cease after is_exiting, and everything after "is terminated". So we're really only discussing the relatively small window between those two points. I'm arguing that there is no need to process handshakes from the start of that Window, rather than from the end. The basic sequence is:

  1. set is_exiting -> thread is no longer of interest to JVM TI or any handshakes related to JVM TI or Java code
  2. set java.lang.Thread status to TERMINATED -> thread is now dead to Java
  3. JFR::on_thread_exit() -> thread is now "dead" to JFR
  4. barrier_set()->on_thread_deatch() -> no more oop interaction so no need for further safepoints
  5. ThreadSMRSupport::remove_thread -> thread no longer in main ThreadsList
  6. set _thread_terminated

You can see the comment: "These things needs to be done while we are still a Java Thread"

That comment is referring to the thread destructor process where we must still be seen to be a JavaThread and not a basic Thread - ie those actions must happen before the end of ~JavaThread. (We had issues where we made calls to virtual functions from ~Thread which didn't dispatch correctly.)

@robehn
Copy link
Contributor

robehn commented May 31, 2022

A handshake with a thread is only needed to interact with that thread in some way and we don't interact with "terminated" threads - so no handshakes needed.

We interact with all JT on a ThreadsList, that's what ThreadsList do, stop the JT from exiting so we can interact with it.

  1. barrier_set()->on_thread_deatch() -> no more oop interaction so no need for further safepoints

Safepoints and handshakes are the same, a GC needs to beable to access the GC data in the JT until 4.
Regardless if the GC choose to access them via handshake or a safepoint.

@pchilano
Copy link
Contributor Author

pchilano commented May 31, 2022

@dholmes-ora originally the idea was that if a JT is on a ThreadsList it will respond to handshakes. Note that while on the ThreadsList it may participate in safepoints. Since we also touch oops after "thread is exiting" we cannot stop responding to handshake after this stage. (ensure_join)

At one point I actually had a patch which removed the terminated state all together, and instead used on or off ThreadsList, which I think is the right approach, reducing complexity.

Anyhow a way longer discussion, this seems fine for now @pchilano , thanks!

Thanks for the review Robbin!

@dcubed-ojdk
Copy link
Member

dcubed-ojdk commented Jun 1, 2022

I'm planning to review this after I finish catching up from being on vacation.
However, I don't think that @pchilano needs to wait for my review since the
version of JDK-8284632 that we (tested and) integrated is @robehn's simpler
rewrite of my original fix. If @robehn is happy with this fix, then I think it is
okay for @pchilano to proceed once he is done with his testing.

Since I also need to retest for the original memory leak, that will also delay
when I'll be able to give @pchilano my complete feedback.

@pchilano
Copy link
Contributor Author

pchilano commented Jun 2, 2022

/integrate

@openjdk
Copy link

openjdk bot commented Jun 2, 2022

Going to push as commit 5acac22.
Since your change was applied there have been 224 commits pushed to the master branch:

  • bddef71: 8287724: Fix various issues with msys2
  • 6ff2d89: 8287496: Alternative virtual thread implementation that maps to OS thread
  • 199832a: 8283466: C2: missing skeleton predicates in peeled loop
  • a82417f: 8233269: Improve handling of JAVA_ARGS
  • d7341ae: 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64
  • 07d2450: 8213531: Test javax/swing/border/TestTitledBorderLeak.java fails
  • 6030c0e: 8287118: Use monospace font for annotation default values
  • 72bcf2a: 4511638: Double.toString(double) sometimes produces incorrect results
  • 2f19144: 8282024: add EscapeAnalysis statistics under PrintOptoStatistics
  • cdb4768: 8287396: LIR_Opr::vreg_number() and data() can return negative number
  • ... and 214 more: https://git.openjdk.java.net/jdk/compare/5bea46110c3ec9c6c17c00b13d1578cb2981ce51...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated label Jun 2, 2022
@openjdk openjdk bot closed this Jun 2, 2022
@openjdk openjdk bot removed ready rfr labels Jun 2, 2022
@openjdk
Copy link

openjdk bot commented Jun 2, 2022

@pchilano Pushed as commit 5acac22.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Copy link
Member

@dcubed-ojdk dcubed-ojdk left a comment

Sorry for the late review. I only found minor things. Please don't
do anything with my review yet. I still need to add my tracker
code and run this fix thru my stress testing.

Very nice job resolving this issue.

@@ -1364,6 +1364,7 @@ static bool is_daemon(oop threadObj) {
// cleanup_failed_attach_current_thread as well.
void JavaThread::exit(bool destroy_vm, ExitType exit_type) {
assert(this == JavaThread::current(), "thread consistency check");
assert(!is_exiting(), "should not be exiting or terminated already");
Copy link
Member

@dcubed-ojdk dcubed-ojdk Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm... The old destroy_vm == true branch assert was:

assert(!is_terminated() && !is_exiting(), "must not be exiting");

and the new assert mesg has "or terminated", but the assert is only
checking !is_exiting() and doesn't not include !is_terminated().
So the old assert checked both conditions and only mumbled about
"exiting" and the new assert checks one condition and mumbles
about both conditions.

Copy link
Contributor Author

@pchilano pchilano Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is_exiting() also checks is_terminated() internally, so it returns true for the _thread_exiting, _thread_terminated and _vm_exited cases (false only for the _not_terminated case). Since the extra !is_terminated() check was redundant I removed it. Also since the assert will trigger for both the exiting and terminated cases I added both to the assert msg.

// we can just put in the exiting state and it will be correctly handled.
// Also, no more async exceptions will be added to the queue after this point.
set_terminated(_thread_exiting);
ThreadService::current_thread_exiting(this, is_daemon(threadObj()));
Copy link
Member

@dcubed-ojdk dcubed-ojdk Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously, we didn't call ThreadService::current_thread_exiting() in the
destroy_vm == true branch. Is that going to result in some change in
behavior?

Copy link
Contributor Author

@pchilano pchilano Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That call decrements a counter used for some stats and for determining the size of the thread array in ThreadListEnumerator. But I don't see any issues on doing that since this thread is actually exiting.

// We call BarrierSet::barrier_set()->on_thread_detach() here so no touching of oops after this point.
Threads::remove(this, daemon);
Copy link
Member

@dcubed-ojdk dcubed-ojdk Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the new comment line!

};
threadCreator.setDaemon(true);
threadCreator.start();
test(timeMax);
Copy link
Member

@dcubed-ojdk dcubed-ojdk Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, but now the test is going to execute for twice timeMax which might be
a bit of a surprise... In particular the usage() mesg is now wrong.

Copy link
Member

@dcubed-ojdk dcubed-ojdk Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, the @bug line is not updated with this bug ID.

Copy link
Contributor Author

@pchilano pchilano Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, we could fix this in a new bug.

};
threadCreator.setDaemon(true);
threadCreator.start();
test(timeMax);
Copy link
Member

@dcubed-ojdk dcubed-ojdk Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, but now the test is going to execute for twice timeMax which might be
a bit of a surprise... In particular the usage() mesg is now wrong.

Copy link
Member

@dcubed-ojdk dcubed-ojdk Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, the @bug line is not updated with this bug ID.

Copy link
Contributor Author

@pchilano pchilano Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, we could fix this in a new bug.

@pchilano
Copy link
Contributor Author

pchilano commented Jun 3, 2022

Thanks for taking a look Dan. Let me know when you have the results of your stress testing.

@dcubed-ojdk
Copy link
Member

dcubed-ojdk commented Jun 4, 2022

StressWrapper_StopAtExit.jtr release bits:

----------System.out:(10/297)----------

Agent_OnLoad started
Agent_OnLoad finished

About to execute for 7200 seconds.
Executed 27471345 loops in 7200 seconds.
About to execute for 7200 seconds.
Executed 12930003 loops in 7200 seconds.
vm_exit: dcubed_async_global_alloc_cnt=232552804
vm_exit: dcubed_async_global_release_cnt=232552804
----------System.err:(1852/93678)----------

StressWrapper_StopAtExit.jtr fastdebug bits:

----------System.out:(10/294)----------

Agent_OnLoad started
Agent_OnLoad finished

About to execute for 7200 seconds.
Executed 18516793 loops in 7200 seconds.
About to execute for 7200 seconds.
Executed 9128937 loops in 7200 seconds.
vm_exit: dcubed_async_global_alloc_cnt=29621450
vm_exit: dcubed_async_global_release_cnt=29621450
----------System.err:(1660/83996)----------

StressWrapper_StopAtExit.jtr slowdebug bits:

----------System.out:(10/293)----------

Agent_OnLoad started
Agent_OnLoad finished

About to execute for 7200 seconds.
Executed 8147300 loops in 7200 seconds.
About to execute for 7200 seconds.
Executed 3913063 loops in 7200 seconds.
vm_exit: dcubed_async_global_alloc_cnt=15924123
vm_exit: dcubed_async_global_release_cnt=15924123
----------System.err:(691/34976)----------

No leaks detected in any config.

@pchilano
Copy link
Contributor Author

pchilano commented Jun 6, 2022

StressWrapper_StopAtExit.jtr release bits:

----------System.out:(10/297)----------

Agent_OnLoad started Agent_OnLoad finished

About to execute for 7200 seconds. Executed 27471345 loops in 7200 seconds. About to execute for 7200 seconds. Executed 12930003 loops in 7200 seconds. vm_exit: dcubed_async_global_alloc_cnt=232552804 vm_exit: dcubed_async_global_release_cnt=232552804 ----------System.err:(1852/93678)----------

StressWrapper_StopAtExit.jtr fastdebug bits:

----------System.out:(10/294)----------

Agent_OnLoad started Agent_OnLoad finished

About to execute for 7200 seconds. Executed 18516793 loops in 7200 seconds. About to execute for 7200 seconds. Executed 9128937 loops in 7200 seconds. vm_exit: dcubed_async_global_alloc_cnt=29621450 vm_exit: dcubed_async_global_release_cnt=29621450 ----------System.err:(1660/83996)----------

StressWrapper_StopAtExit.jtr slowdebug bits:

----------System.out:(10/293)----------

Agent_OnLoad started Agent_OnLoad finished

About to execute for 7200 seconds. Executed 8147300 loops in 7200 seconds. About to execute for 7200 seconds. Executed 3913063 loops in 7200 seconds. vm_exit: dcubed_async_global_alloc_cnt=15924123 vm_exit: dcubed_async_global_release_cnt=15924123 ----------System.err:(691/34976)----------

No leaks detected in any config.

Great, thanks for confirming Dan!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-runtime integrated
4 participants