Skip to content
This repository has been archived by the owner. It is now read-only.

8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC #149

Closed
wants to merge 11 commits into from

Conversation

JornVernee
Copy link
Member

@JornVernee JornVernee commented Jun 25, 2021

This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.

Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.

The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.

FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.

Testing: local running of jdk_foreign on Windows and Linux (WSL). Tier 1-3


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 149

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

Using diff file

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jun 25, 2021

👋 Welcome back jvernee! 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 openjdk bot commented Jun 25, 2021

@JornVernee The following labels will be automatically applied to this pull request:

  • core-libs
  • hotspot

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

@openjdk openjdk bot added hotspot core-libs labels Jun 25, 2021
@JornVernee
Copy link
Member Author

@JornVernee JornVernee commented Jun 25, 2021

/help label

@openjdk
Copy link

@openjdk openjdk bot commented Jun 25, 2021

@JornVernee Available commands:

  • cc - add or remove an additional classification label
  • clean - Mark the backport pull request as a clean backport
  • contributor - adds or removes additional contributors for a PR
  • covered - used when employer has signed the OCA
  • csr - require a compatibility and specification request (CSR) for this pull request
  • help - shows this text
  • integrate - performs integration of the changes in the PR
  • issue - edit the list of issues that this PR solves
  • label - add or remove an additional classification label
  • open - Set the pull request state to "open"
  • reviewer - manage additional reviewers for a PR
  • reviewers - set the number of additional required reviewers for this PR
  • signed - used after signing the OCA
  • solves - edit the list of issues that this PR solves
  • sponsor - performs integration of a PR that is authored by a non-committer
  • summary - updates the summary in the commit message
  • test - used to run tests

OptimizedEntryBlob::FrameData* OptimizedEntryBlob::frame_data_for_frame(const frame& frame) const {
ShouldNotCallThis();
return nullptr;
}

Copy link
Member Author

@JornVernee JornVernee Jun 28, 2021

Choose a reason for hiding this comment

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

FWIW, stubs were missing on some platforms, and this seems to have been fine before, but now started causing compilation errors, so I've added them here.

@@ -928,6 +928,7 @@ void ThreadSafepointState::handle_polling_page_exception() {
if( nm->is_at_poll_return(real_return_addr) ) {
// See if return type is an oop.
bool return_oop = nm->method()->is_returning_oop();
HandleMark hm(self);
Copy link
Member Author

@JornVernee JornVernee Jun 28, 2021

Choose a reason for hiding this comment

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

I was seeing an assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark when the existing code allocates the Handle for return_value in the code down below. It seems to be a simple case of a missing handle mark, so I've added it here. (looking at the stack trace in the error log, the caller frame is native code, so I don't think we can expect the caller to have a HandleMark).

Copy link
Member

@dholmes-ora dholmes-ora Jul 14, 2021

Choose a reason for hiding this comment

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

How does native code reach a safepoint polling point?

Copy link
Member Author

@JornVernee JornVernee Jul 15, 2021

Choose a reason for hiding this comment

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

The stack trace looks like this:

Current thread (0x000002a2489f0b50):  JavaThread "Thread-4551" [_thread_in_Java, id=24920, stack(0x000000d9e0500000,0x000000d9e0600000)]

Stack: [0x000000d9e0500000,0x000000d9e0600000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xae6651]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:235)
V  [jvm.dll+0xda3f25]  VMError::report+0x1005  (vmError.cpp:739)
V  [jvm.dll+0xda58ae]  VMError::report_and_die+0x7fe  (vmError.cpp:1549)
V  [jvm.dll+0xda5fe4]  VMError::report_and_die+0x64  (vmError.cpp:1330)
V  [jvm.dll+0x4ceca7]  report_vm_error+0xb7  (debug.cpp:282)
V  [jvm.dll+0x6511be]  HandleArea::allocate_handle+0x3e  (handles.cpp:35)
V  [jvm.dll+0xb8e334]  ThreadSafepointState::handle_polling_page_exception+0x314  (safepoint.cpp:939)
C  0x000002a035d8caa7

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~SafepointBlob
J 639 c1 java.lang.invoke.LambdaForm$MH+0x000000080101b800.invoke(Ljava/lang/Object;)V java.base@18-internal (87 bytes) @ 0x000002a03635f7b4 [0x000002a03635f4a0+0x0000000000000314]
J 620 c1 java.lang.invoke.LambdaForm$MH+0x0000000801018c00.invoke(Ljava/lang/Object;)V java.base@18-internal (37 bytes) @ 0x000002a036353e0c [0x000002a036353720+0x00000000000006ec]
v  ~BufferBlob::�mэYсссс��ЫGў�

So I think the 'native code' is something being called by the safepoint blob, but I'm not sure why it's marked with a C instead of V in the stack trace (maybe just a stack unwind failure?).

FWIW, this part has already been fixed as part of: #173 (not sure why it still shows up in the diff)

Copy link
Member

@dholmes-ora dholmes-ora Jul 15, 2021

Choose a reason for hiding this comment

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

Okay so we're not actually _thread_in_native it is just a chunk of VM generated code. Something still seems off to me about the need for the HandleMark but that isn't your problem.

#ifdef ASSERT
void JavaThread::verify_frame_info() {
assert((!has_last_Java_frame() && java_call_counter() == 0) ||
(has_last_Java_frame() && java_call_counter() > 0),
"unexpected frame info: has_last_frame=%d, java_call_counter=%d",
has_last_Java_frame(), java_call_counter());
}
#endif
Copy link
Member Author

@JornVernee JornVernee Jun 28, 2021

Choose a reason for hiding this comment

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

I reduced some duplication here while debugging, but this change is not strictly needed (though a nice cleanup, IMO). Let me know, and I could remove this part if preferred.

@JornVernee
Copy link
Member Author

@JornVernee JornVernee commented Jun 28, 2021

/label remove hotspot
/label add hotspot-gc
/label add hotspot-runtime

@openjdk openjdk bot removed the hotspot label Jun 28, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jun 28, 2021

@JornVernee
The hotspot label was successfully removed.

@openjdk openjdk bot added the hotspot-gc label Jun 28, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jun 28, 2021

@JornVernee
The hotspot-gc label was successfully added.

@openjdk openjdk bot added the hotspot-runtime label Jun 28, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jun 28, 2021

@JornVernee
The hotspot-runtime label was successfully added.

@JornVernee JornVernee marked this pull request as ready for review Jun 28, 2021
@openjdk openjdk bot added the rfr label Jun 28, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jun 28, 2021

Webrevs

Copy link

@iwanowww iwanowww left a comment

Looks good.

src/hotspot/cpu/x86/frame_x86.cpp Show resolved Hide resolved
@@ -1125,6 +1125,8 @@ class JavaThread: public Thread {
void set_requires_cross_modify_fence(bool val) PRODUCT_RETURN NOT_PRODUCT({ _requires_cross_modify_fence = val; })

private:
DEBUG_ONLY(void verify_frame_info();)

Choose a reason for hiding this comment

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

If you declare verify_frame_info as returning a bool (and just put a return true; at the end of JavaThread::verify_frame_info()), you can call it as:

assert(verify_frame_info(), "unexpected frame info");

Copy link
Member Author

@JornVernee JornVernee Jul 13, 2021

Choose a reason for hiding this comment

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

Thanks for the suggestion. I'd like to keep it the way it is though, so that the assert message contains the has_last_frame & java_call_counter values. (this was one of the reason I did this refactor as well, since the assert I was hitting out of those 3 didn't contain that info).

Choose a reason for hiding this comment

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

You can keep the assert inside verify_frame_info() which dumps additional data. (Yes, it's a bit confusing: assert inside an assert :-) )

Choose a reason for hiding this comment

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

FTR I'm fine with it either way.

@openjdk
Copy link

@openjdk openjdk bot commented Jul 13, 2021

@JornVernee 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:

8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC

Reviewed-by: vlivanov, dholmes

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 106 new commits pushed to the master branch:

  • 2dddcce: 8270858: Problem List java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Linux
  • 1350e2b: 8270556: Exclude security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA
  • e104ded: 8268635: Corrupt oop in ClassLoaderData
  • a32d2ee: 8269276: Additional tests for MessageDigest with different providers
  • 7b4d84c: 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848
  • 72db09b: 8266313: (JEP-356) - RandomGenerator spec implementation requirements tightly coupled to JDK internal classes
  • 3bbd233: 8270075: SplittableRandom extends AbstractSplittableGenerator
  • 381bd62: 8266889: [macosx-aarch64] Crash with SIGBUS in MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002 test run
  • 82c256e: 8259499: Handling type arguments from outer classes for inner class in javadoc
  • e5db9a9: 8268620: InfiniteLoopException test may fail on x86 platforms
  • ... and 96 more: https://git.openjdk.java.net/jdk17/compare/e4c5446340605b112e0918fa9dcb48aaeaa730c8...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 Jul 13, 2021
Copy link
Member

@dholmes-ora dholmes-ora left a comment

Hi Jorn,

I can't comment on all the details here - especially in the x86_64 upcall handler code. The mapping to JavaCallWrapper seems reasonable but there are a few differences that I'm now assuming stem from the fact upcalls start _thread_in_native while JCW starts from _thread_in_vm?

Some minor comments and queries below (mostly issues with existing code that you copied).

Thanks,
David

src/hotspot/share/prims/universalUpcallHandler.cpp Outdated Show resolved Hide resolved
src/hotspot/share/prims/universalUpcallHandler.cpp Outdated Show resolved Hide resolved
src/hotspot/share/prims/universalUpcallHandler.cpp Outdated Show resolved Hide resolved
src/hotspot/share/prims/universalUpcallHandler.cpp Outdated Show resolved Hide resolved
src/hotspot/share/prims/universalUpcallHandler.cpp Outdated Show resolved Hide resolved
src/hotspot/share/prims/universalUpcallHandler.cpp Outdated Show resolved Hide resolved
@@ -71,6 +72,93 @@ void ProgrammableUpcallHandler::detach_thread(Thread* thread) {
vm->functions->DetachCurrentThread(vm);
}

// modelled after JavaCallWrapper::JavaCallWrapper
Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {
Copy link
Member

@dholmes-ora dholmes-ora Jul 14, 2021

Choose a reason for hiding this comment

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

This should return JavaThread not Thread.

Copy link
Member Author

@JornVernee JornVernee Jul 15, 2021

Choose a reason for hiding this comment

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

Thanks.

I've been careful here to return a Thread* since the result is stored in r15_thread and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:

Subclass
+---
| {Subclass vtable pointer}
| +--- (base class Super)
| | {Super vtable pointer}
| +---
+---

So, I thought plainly using a JavaThread* in generated machine code where a Thread* was expected could cause trouble, since the pointer needs to be offset for the type conversion.

But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance:

class SuperA {
public:
    virtual void foo();
};

class SuperB {
public:
    virtual void bar();
};

class Sub : public SuperA, public SuperB {
public:
    virtual void baz();
};

Results in:

class Sub	size(16):
	+---
 0	| +--- (base class SuperA)
 0	| | {vfptr}
	| +---
 8	| +--- (base class SuperB)
 8	| | {vfptr}
	| +---
	+---

Sub::$vftable@SuperA@:
	| &Sub_meta
	|  0
 0	| &SuperA::foo 
 1	| &Sub::baz 

Sub::$vftable@SuperB@:
	| -8
 0	| &SuperB::bar 

Sub::baz this adjustor: 0

(https://godbolt.org/z/1665fWzff)

It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between SuperB* and Sub* would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts).

The result of on_entry is stored in r15_thread, so I guess I'm wondering if it's safe to store a JavaThread* instead of a Thread* in r15, and other code, which may expect r15 to hold a Thread*, is guaranteed to keep working? (FWIW, after changing the return type to JavaThread* the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC).

Copy link
Member Author

@JornVernee JornVernee Jul 15, 2021

Choose a reason for hiding this comment

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

Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff

Copy link
Contributor

@vnkozlov vnkozlov Jul 15, 2021

Choose a reason for hiding this comment

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

@JornVernee I have small correct to your comment. We use simple inheritance for Thread subclasses. Their instances have one vtbl pointer at the same offset as in base class. But this pointer will point to separate vtable for each subclass (and base class). The layout (sequence) of methods pointers in vtable is the same in base class and subclasses. But subclass specific methods pointers will be different.

The only issue is that you have to make sure to cast passed object pointer to correct subclass (or base class). Otherwise you will get incorrect vtable and incorrect virtual methods pointers.

R15 is used by our JIT compiled code and Interpreter code which are executed only in JavaThread so the pinter it contains is JavaThread*

Copy link
Member Author

@JornVernee JornVernee Jul 16, 2021

Choose a reason for hiding this comment

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

Thanks Vladimir. This also matches what I was seeing in compiler explorer, but I wasn't sure if we could assume it always worked like that with every C++ compiler.

It sound like R15 is expected to hold a JavaThread* though, so making the return type of on_entry be JavaThread* as David suggested seems correct.

Thanks

@@ -928,6 +928,7 @@ void ThreadSafepointState::handle_polling_page_exception() {
if( nm->is_at_poll_return(real_return_addr) ) {
// See if return type is an oop.
bool return_oop = nm->method()->is_returning_oop();
HandleMark hm(self);
Copy link
Member

@dholmes-ora dholmes-ora Jul 14, 2021

Choose a reason for hiding this comment

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

How does native code reach a safepoint polling point?

src/hotspot/share/runtime/thread.cpp Outdated Show resolved Hide resolved
@JornVernee
Copy link
Member Author

@JornVernee JornVernee commented Jul 15, 2021

The mapping to JavaCallWrapper seems reasonable but there are a few differences that I'm now assuming stem from the fact upcalls start _thread_in_native while JCW starts from _thread_in_vm?

The main difference stems from the fact that, since these upcalls can come from non-JNI native code, we can not assume that the thread is already attached to the VM, so we do that on the fly instead, and we detach the thread again after the upcall (if needed). Those are what the call to maybe_attach_and_get_thread at the start of on_entry, and detach_thread call at the end of on_exit are for.

The other thing is that there is no stack watermark check at the end of on_exit. This check is guarded by a check if the thread has any pending exceptions in JavaCallWrapper, but since a panama upcall is not allowed to throw any exceptions, I've changed that to an assert that checks that there are no pending exceptions at that point instead.

The last thing is that we transition directly from _thread_in_native to _thread_in_Java, which changes some of the thread transition code.

Other than that, I've tried to mimic what JavaCallWrapper does as closely as possible.

Is there anything else that looks different?

@mlbridge
Copy link

@mlbridge mlbridge bot commented Jul 15, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

On 15/07/2021 10:29 pm, Jorn Vernee wrote:

On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

Assert frame is correct type in frame_data_for_frame

src/hotspot/share/prims/universalUpcallHandler.cpp line 76:

74:
75: // modelled after JavaCallWrapper::JavaCallWrapper
76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {

This should return JavaThread not Thread.

Thanks.

I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:

Wow! Okay I've never seen anyone query this before. AFAIK whatever we
store in r15_thread is required to be a correct pointer to the current
thread object whatever its exact subtype may be. The returned pointer
has to work correctly for virtual functions and can't be a "sliced"
Thread instead of the real type. So as far as I know this "just works"
and I think we'd be in big trouble if it didn't work.

But I don't deal with the under-the-covers parts of the C++ compiler.

David
-----

1 similar comment
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jul 15, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

On 15/07/2021 10:29 pm, Jorn Vernee wrote:

On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

Assert frame is correct type in frame_data_for_frame

src/hotspot/share/prims/universalUpcallHandler.cpp line 76:

74:
75: // modelled after JavaCallWrapper::JavaCallWrapper
76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {

This should return JavaThread not Thread.

Thanks.

I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:

Wow! Okay I've never seen anyone query this before. AFAIK whatever we
store in r15_thread is required to be a correct pointer to the current
thread object whatever its exact subtype may be. The returned pointer
has to work correctly for virtual functions and can't be a "sliced"
Thread instead of the real type. So as far as I know this "just works"
and I think we'd be in big trouble if it didn't work.

But I don't deal with the under-the-covers parts of the C++ compiler.

David
-----

@JornVernee
Copy link
Member Author

@JornVernee JornVernee commented Jul 15, 2021

David, I've addressed your review comments.

For now I went with changing the return type of on_entry to JavaThread*, assuming the potential pointer conversion is not an issue.

I tried for a while to implement a static assert to check that Thread* is trivial convertible to JavaThread* as well, but couldn't find a way to do that at compile time, so left it for now. It looks like C++ 20 has a type trait to check this: https://en.cppreference.com/w/cpp/types/is_pointer_interconvertible_base_of (I think this does what we want). I thought maybe we could just mimic the reference implementation, but looking at for instance the MSVC STL implementation, this type trait is implemented as a compiler intrinsic, so I think we'll have to wait until we are on C++ 20 before adding such a static assert.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Thanks for the updates.

Minor comments below.

David

src/hotspot/share/prims/universalUpcallHandler.cpp Outdated Show resolved Hide resolved
src/hotspot/share/prims/universalUpcallHandler.cpp Outdated Show resolved Hide resolved
@JornVernee
Copy link
Member Author

@JornVernee JornVernee commented Jul 16, 2021

I've addressed the new review comments, changing some Thread* to JavaThread*, removing now redundant casts, and finally noticed that the Thread* being passed to ProgrammableUpcallHandle::detach_thread was not being used, and it was always detaching the current thread instead. This in itself is fine, but then there's no need for the parameter, so I've dropped that.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Updates look good.

Thanks,
David

// Returns the current thread as a JavaThread, or NULL if not attached
static inline JavaThread* current_or_null();
Copy link
Member

@dholmes-ora dholmes-ora Jul 17, 2021

Choose a reason for hiding this comment

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

I hadn't intended to suggest the introduction of this method, but I see now how my comment led to it. It is fine.

@JornVernee
Copy link
Member Author

@JornVernee JornVernee commented Jul 20, 2021

I can't comment on all the details here - especially in the x86_64 upcall handler code.

Vladimir's review covers that part of the patch (confirmed with him), so I will go ahead and integrate this.

@JornVernee
Copy link
Member Author

@JornVernee JornVernee commented Jul 20, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Jul 20, 2021

Going to push as commit 845c31d.
Since your change was applied there have been 108 commits pushed to the master branch:

  • 0cec11d: 8270307: C2: assert(false) failed: bad AD file after JDK-8267687
  • c130451: 8269752: C2: assert(false) failed: Bad graph detected in build_loop_late
  • 2dddcce: 8270858: Problem List java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Linux
  • 1350e2b: 8270556: Exclude security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA
  • e104ded: 8268635: Corrupt oop in ClassLoaderData
  • a32d2ee: 8269276: Additional tests for MessageDigest with different providers
  • 7b4d84c: 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848
  • 72db09b: 8266313: (JEP-356) - RandomGenerator spec implementation requirements tightly coupled to JDK internal classes
  • 3bbd233: 8270075: SplittableRandom extends AbstractSplittableGenerator
  • 381bd62: 8266889: [macosx-aarch64] Crash with SIGBUS in MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002 test run
  • ... and 98 more: https://git.openjdk.java.net/jdk17/compare/e4c5446340605b112e0918fa9dcb48aaeaa730c8...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Jul 20, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jul 20, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jul 20, 2021

@JornVernee Pushed as commit 845c31d.

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
core-libs hotspot-gc hotspot-runtime integrated
4 participants