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

JDK-8277822: Remove debug-only heap overrun checks in os::malloc and friends #6554

Conversation

tstuefe
Copy link
Member

@tstuefe tstuefe commented Nov 25, 2021

After integrating C heap overrun checks into NMT (https://bugs.openjdk.java.net/browse/JDK-8275320), we can now remove debug-only guarding memory for os::malloc() and friends.

This will:

  • reduce complexity of os::malloc, os::free, os::realloc (especially that one since realloc is tricky)
  • saves 48 bytes per malloc in debug builds. In my experiences this can sum up to a quite substantial overhead compared to release builds, especially since malloc allocations are often fine grained.
  • reduce behavioral differences between debug and release builds wrt memory layout and allocation paths.

Currently, we have always-on heap overrun checks in debug VMs. In order to preserve this feature after the patch, NMT is switched always on per default in debug builds (but can be switched off if needed, as opposed to the baked-in debug-only guards today).

We use NMT level summary here, which is very cheap since we don't track stacks, we just count some numbers in NMT categories. Memory overhead will still be a lot less than what we paid before with the quite generous debug-only guards.

Finally, this would also be a good coverage test for NMT.

For more information, please refer to the umbrella JBS (https://bugs.openjdk.java.net/browse/JDK-8275301).


Memory stomp reports are better now since NMT buffer overrun reporting (see JDK-8275320) is better.

Before:

[0.051s][warning][malloc,free] ## nof_mallocs = 11948, nof_frees = 2017
[0.051s][warning][malloc,free] ## memory stomp:
[0.051s][warning][malloc,free] GuardedMemory(0x00007fb3115ea560) base_addr=0x00007fb30c1df630 tag=0x0000000000000000 user_size=4096 user_data=0x00007fb30c1df650
[0.051s][warning][malloc,free]   Header guard @0x00007fb30c1df630 is OK
[0.051s][warning][malloc,free]   Trailer guard @0x00007fb30c1e0650 is BROKEN
[0.051s][warning][malloc,free]   User data appears to be in use
# To suppress the following error report, specify this argument

Old reporting was susceptible to C-heap corruption: a sufficiently corrupted C-heap caused the libc to abort before reporting was completed:

thomas@starfish:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ ./images/jdk/bin/java -XX:+UseNewCode
[0.047s][warning][malloc,free] ## nof_mallocs = 11948, nof_frees = 2017
[0.047s][warning][malloc,free] ## memory stomp:
java: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
Aborted (core dumped)

The new reports, done by NMT, print out a hex dump of the corrupted area, before calling into libc. So this printout is something we always get, even if C-heap is corrupted beyond help:

thomas@starfish:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ ./images/jdk/bin/java -XX:+UseNewCode
NMT Block at 0x00007f33c01a8e70, corruption at: 0x00007f33c01a9e80: 
0x00007f33c01a8df0:   00 00 00 00 00 00 00 00 75 00 00 00 00 00 00 00
0x00007f33c01a8e00:   50 00 00 00 00 00 00 00 00 00 00 00 01 00 9e e9
0x00007f33c01a8e10:   a8 b2 46 c6 33 7f 00 00 d0 7a 11 c0 33 7f 00 00
0x00007f33c01a8e20:   f0 4e 11 c0 33 7f 00 00 50 50 52 c6 33 7f 00 00
0x00007f33c01a8e30:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8e40:   00 00 00 00 00 00 00 00 a0 ae 52 c6 33 7f 00 00
0x00007f33c01a8e50:   ff b7 f7 c5 33 7f 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8e60:   e8 8e 00 00 00 00 00 00 25 10 00 00 00 00 00 00
0x00007f33c01a8e70:   00 10 00 00 00 00 00 00 00 00 00 00 0f 00 9e e9
0x00007f33c01a8e80:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8e90:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8ea0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8eb0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8ec0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8ed0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8ee0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
...
0x00007f33c01a9e00:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e10:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e20:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e30:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e40:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e50:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e60:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e70:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e80:   00 00 00 00 00 00 00 00 81 01 00 00 00 00 00 00
0x00007f33c01a9e90:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9ea0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9eb0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9ec0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9ed0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9ee0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9ef0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
# To suppress the following error report, specify this argument

At first glance it seems that "nof_mallocs" etc are missing from this output. This is true, I removed them. They are not needed since the hs-err file contains an NMT summary report, which has more and finer grained information than that.


Tests:

  • GHAs (the windows failures are related to 8241403: "JavaThread::get_thread_name() should be ThreadSMR-aware")
  • we tested this patch for several days in SAP nightlies
  • manual tests x64 and x86 Linux

Progress

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

Issue

  • JDK-8277822: Remove debug-only heap overrun checks in os::malloc and friends

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6554

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

Using diff file

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

@bridgekeeper
Copy link

bridgekeeper bot commented Nov 25, 2021

👋 Welcome back stuefe! 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.

@tstuefe tstuefe force-pushed the JDK-8277822-Remove-debug-only-heap-overrun-checks-in-os-malloc-and-friends branch from 44ed71c to 9f0e0d7 Compare Nov 25, 2021
@openjdk
Copy link

openjdk bot commented Nov 25, 2021

@tstuefe 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 hotspot-runtime-dev@openjdk.org label Nov 25, 2021
@tstuefe tstuefe force-pushed the JDK-8277822-Remove-debug-only-heap-overrun-checks-in-os-malloc-and-friends branch 4 times, most recently from e6163f8 to f0bca7a Compare Nov 26, 2021
@tstuefe tstuefe force-pushed the JDK-8277822-Remove-debug-only-heap-overrun-checks-in-os-malloc-and-friends branch from f0bca7a to a571f6d Compare Nov 30, 2021
@tstuefe tstuefe marked this pull request as ready for review Nov 30, 2021
@openjdk openjdk bot added the rfr Pull request is ready for review label Nov 30, 2021
@mlbridge
Copy link

mlbridge bot commented Nov 30, 2021

Webrevs

@bridgekeeper
Copy link

bridgekeeper bot commented Jan 4, 2022

@tstuefe This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

Copy link
Contributor

@coleenp coleenp left a comment

This looks like a very nice cleanup, although I have a couple of questions.

}
static void break_if_ptr_caught(void* ptr) {
if (p2i(ptr) == (intptr_t)MallocCatchPtr) {
log_warning(malloc, free)("ptr caught: " PTR_FORMAT, p2i(ptr));
Copy link
Contributor

@coleenp coleenp Jan 14, 2022

Choose a reason for hiding this comment

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

If this is the same as MallocCatchPtr, doesn't this output simply print MallocCatchPtr?

Copy link
Contributor

@coleenp coleenp Jan 14, 2022

Choose a reason for hiding this comment

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

I don't understand what this does. ie. please tell what it does in a comment.

Copy link
Member Author

@tstuefe tstuefe Jan 14, 2022

Choose a reason for hiding this comment

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

If this is the same as MallocCatchPtr, doesn't this output simply print MallocCatchPtr?

Yes

I don't understand what this does. ie. please tell what it does in a comment.

Oh, I did not invent it, I just unified the various places where before we checked MallocCatchPtr. E.g. here:

if ((intptr_t)ptr == (intptr_t)MallocCatchPtr) {
log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
breakpoint();
}

The coding is old, I believe it predates the OpenJDK. I would love to get rid of MallocCatchPtr, if nobody uses it anymore.

@@ -38,7 +38,6 @@
#include "logging/log.hpp"
#include "logging/logStream.hpp"
#include "memory/allocation.inline.hpp"
#include "memory/guardedMemory.hpp"
Copy link
Contributor

@coleenp coleenp Jan 14, 2022

Choose a reason for hiding this comment

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

Should this file now be deleted if not used?

Copy link
Contributor

@coleenp coleenp Jan 14, 2022

Choose a reason for hiding this comment

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

I see it's used in jniCheck.cpp - was it double-guarded ? It's ok to leave this maybe to investigate for another time.

Copy link
Member Author

@tstuefe tstuefe Jan 14, 2022

Choose a reason for hiding this comment

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

jniCheck.cpp was double guarded, yes. It's also horrible since it does a complete copy of the user buffer, including payload. I'd love to throw it away, have actually planned for it. But people get suspicious if I remove too much in a single RFE, therefore I wanted to keep this for a separate discussion. The discussion, in this case, is that we would have to bind NMT=enabled to -XcheckJni to get NMT to take care of overflow checks.

Copy link
Contributor

@coleenp coleenp Jan 14, 2022

Choose a reason for hiding this comment

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

Hm, yes, I see maybe it's not a good idea since NMT is enabled by default only on debug and Xcheck:jni is a product level feature. Maybe Xcheck:jni can turn on NMT though. I suppose that would be ok.

Copy link
Member Author

@tstuefe tstuefe Jan 14, 2022

Choose a reason for hiding this comment

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

I had the same thought, but it would be good to have this discussion separately.


const NMT_TrackingLevel level = MemTracker::tracking_level();

// If NMT is enabled, this checks for heap overwrites, then de-accounts the old block.
Copy link
Contributor

@coleenp coleenp Jan 14, 2022

Choose a reason for hiding this comment

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

Could you provide a link where NMT checks for heap overwrites to save me looking for it? Thanks.

@openjdk
Copy link

openjdk bot commented Jan 14, 2022

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

8277822: Remove debug-only heap overrun checks in os::malloc and friends

Reviewed-by: coleenp, zgu

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

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 Pull request is ready to be integrated label Jan 14, 2022
@tstuefe
Copy link
Member Author

tstuefe commented Jan 14, 2022

Hi Coleen,

thanks for looking at this! I already had given up hope :)

Could you provide a link where NMT checks for heap overwrites to save me looking for it? Thanks.

Sure. This came all with https://bugs.openjdk.java.net/browse/JDK-8275320.

Upon free (either one of os::free or os::realloc) we call, if NMT is enabled, MallocTracker::record_free -> MallocHeader::release() -> MallocHeader::check_block_integrity(). There, both header and footer canary of the block-to-be-freed are checked, as well as some other stuff.

void MallocHeader::check_block_integrity() const {
#define PREFIX "NMT corruption: "
// Note: if you modify the error messages here, make sure you
// adapt the associated gtests too.
// Weed out obviously wrong block addresses of NULL or very low
// values. Note that we should not call this for ::free(NULL),
// which should be handled by os::free() above us.
if (((size_t)p2i(this)) < K) {
fatal(PREFIX "Block at " PTR_FORMAT ": invalid block address", p2i(this));
}
// From here on we assume the block pointer to be valid. We could
// use SafeFetch but since this is a hot path we don't. If we are
// wrong, we will crash when accessing the canary, which hopefully
// generates distinct crash report.
// Weed out obviously unaligned addresses. NMT blocks, being the result of
// malloc calls, should adhere to malloc() alignment. Malloc alignment is
// specified by the standard by this requirement:
// "malloc returns a pointer which is suitably aligned for any built-in type"
// For us it means that it is *at least* 64-bit on all of our 32-bit and
// 64-bit platforms since we have native 64-bit types. It very probably is
// larger than that, since there exist scalar types larger than 64bit. Here,
// we test the smallest alignment we know.
// Should we ever start using std::max_align_t, this would be one place to
// fix up.
if (!is_aligned(this, sizeof(uint64_t))) {
print_block_on_error(tty, (address)this);
fatal(PREFIX "Block at " PTR_FORMAT ": block address is unaligned", p2i(this));
}
// Check header canary
if (_canary != _header_canary_life_mark) {
print_block_on_error(tty, (address)this);
fatal(PREFIX "Block at " PTR_FORMAT ": header canary broken.", p2i(this));
}
#ifndef _LP64
// On 32-bit we have a second canary, check that one too.
if (_alt_canary != _header_alt_canary_life_mark) {
print_block_on_error(tty, (address)this);
fatal(PREFIX "Block at " PTR_FORMAT ": header alternate canary broken.", p2i(this));
}
#endif
// Does block size seems reasonable?
if (_size >= max_reasonable_malloc_size) {
print_block_on_error(tty, (address)this);
fatal(PREFIX "Block at " PTR_FORMAT ": header looks invalid (weirdly large block size)", p2i(this));
}
// Check footer canary
if (get_footer() != _footer_canary_life_mark) {
print_block_on_error(tty, footer_address());
fatal(PREFIX "Block at " PTR_FORMAT ": footer canary broken at " PTR_FORMAT " (buffer overflow?)",
p2i(this), p2i(footer_address()));
}
#undef PREFIX
}

I also added an ASCII picture of the NMT headers:

/*
* Malloc tracking header.
*
* If NMT is active (state >= minimal), we need to track allocations. A simple and cheap way to
* do this is by using malloc headers.
*
* The user allocation is preceded by a header and is immediately followed by a (possibly unaligned)
* footer canary:
*
* +--------------+------------- .... ------------------+-----+
* | header | user | can |
* | | allocation | ary |
* +--------------+------------- .... ------------------+-----+
* 16 bytes user size 2 byte
*
* Alignment:
*
* The start of the user allocation needs to adhere to malloc alignment. We assume 128 bits
* on both 64-bit/32-bit to be enough for that. So the malloc header is 16 bytes long on both
* 32-bit and 64-bit.
*
* Layout on 64-bit:
*
* 0 1 2 3 4 5 6 7
* +--------+--------+--------+--------+--------+--------+--------+--------+
* | 64-bit size | ...
* +--------+--------+--------+--------+--------+--------+--------+--------+
*
* 8 9 10 11 12 13 14 15 16 ++
* +--------+--------+--------+--------+--------+--------+--------+--------+ ------------------------
* ... | bucket idx | pos idx | flags | unused | canary | ... User payload ....
* +--------+--------+--------+--------+--------+--------+--------+--------+ ------------------------
*
* Layout on 32-bit:
*
* 0 1 2 3 4 5 6 7
* +--------+--------+--------+--------+--------+--------+--------+--------+
* | alt. canary | 32-bit size | ...
* +--------+--------+--------+--------+--------+--------+--------+--------+
*
* 8 9 10 11 12 13 14 15 16 ++
* +--------+--------+--------+--------+--------+--------+--------+--------+ ------------------------
* ... | bucket idx | pos idx | flags | unused | canary | ... User payload ....
* +--------+--------+--------+--------+--------+--------+--------+--------+ ------------------------
*
* Notes:
* - We have a canary in the two bytes directly preceding the user payload. That allows us to
* catch negative buffer overflows.
* - On 32-bit, due to the smaller size_t, we have some bits to spare. So we also have a second
* canary at the very start of the malloc header (generously sized 32 bits).
* - The footer canary consists of two bytes. Since the footer location may be unaligned to 16 bits,
* the bytes are stored individually.
*/

that may clarify things. We have two canaries, one in the header directly preceding the user payload, one following the user payload.

@coleenp
Copy link
Contributor

coleenp commented Jan 14, 2022

thanks for looking at this! I already had given up hope :)

Lots of large reviews seem to fallen through the cracks for me. I'd just noticed it. I'd also missed the NMT change. I think this is a nice cleanup. Hopefully @zhengyu123 can review this also.

@tstuefe
Copy link
Member Author

tstuefe commented Jan 14, 2022

thanks for looking at this! I already had given up hope :)

Lots of large reviews seem to fallen through the cracks for me. I'd just noticed it. I'd also missed the NMT change. I think this is a nice cleanup. Hopefully @zhengyu123 can review this also.

Thank you. It is not that urgent, we missed jdk18 already. OTOH, larger cleanups like this are better placed at the start of a new release anyway, so no harm done.

@coleenp
Copy link
Contributor

coleenp commented Jan 14, 2022

Yes, much better as a JDK 19 change.

Copy link
Contributor

@zhengyu123 zhengyu123 left a comment

LGTM

@@ -543,7 +543,7 @@ const intx ObjectAlignmentInBytes = 8;
"compression. Otherwise the level must be between 1 and 9.") \
range(0, 9) \
\
product(ccstr, NativeMemoryTracking, "off", \
product(ccstr, NativeMemoryTracking, DEBUG_ONLY("summary") NOT_DEBUG("off"), \
Copy link
Member

@dholmes-ora dholmes-ora Jan 18, 2022

Choose a reason for hiding this comment

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

Hi Thomas,

I'm a bit concerned about always enabling part of NMT in debug as that affects the bulk of our hotspot testing. What is the potential overhead from enabling NMT this way? We would need to run this patch through our CI to ensure it doesn't introduce any issues.

Cheers,
David

Copy link
Member Author

@tstuefe tstuefe Jan 18, 2022

Choose a reason for hiding this comment

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

Hi David,

I understand your concern. I have had this patch in our internal tests enabled for several months now, but am fine with you guys doing more tests.

My arguments for this:

  1. using NMT in debug builds in place of the old hard wired fences should be less overhead, not more. NMT is quite frugal. NMT=summary does:
  • increase the counter per NMT category (basically atomic-incing a number in a static array)
  • add and populate a malloc header and a footer
    That's it. We did the same thing before. The old code atomically increased two global counters (inc_stat_counter), then added a header and a footer. Only the old header/footer had been much larger than what NMT does. So we use less memory, not more, in debug.
  1. Another argument for this is that NMT is important. It gets used by support, typically in stressful situations. I rather have it thoroughly tested as part of our internal tests. I am not sure that we have ironed out every single NMT issue. NMT feels very stable to me, but there may be lingering issues. But then we should fix them.

All that said, I'd be happy for you to give this patch a spin in your CI. I can hold off the push for a bit.

Cheers, Thomas

Copy link
Member

@dholmes-ora dholmes-ora Jan 18, 2022

Choose a reason for hiding this comment

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

Thanks for the additional info Thomas. I will run it through our CI and report back.

Copy link
Member

@dholmes-ora dholmes-ora Jan 18, 2022

Choose a reason for hiding this comment

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

I'm seeing a timeout with langtools tier1 test tools/javac/failover/CheckAttributedTree.java on macosx-aarch64. It timed out after 9m. I'll try a few re-runs.

Copy link
Member

@dholmes-ora dholmes-ora Jan 18, 2022

Choose a reason for hiding this comment

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

10 re-runs all passed fine - maximum time 3m01s. A re-run on the same machine as previously timed-out was only 47s. So I think we are generally good to go here. Thanks.

Copy link
Contributor

@coleenp coleenp Jan 18, 2022

Choose a reason for hiding this comment

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

Thanks for doing this David.

@tstuefe
Copy link
Member Author

tstuefe commented Jan 19, 2022

Thanks @coleenp, @zhengyu123 and @dholmes-ora

Tests at SAP went through smoothly too.

/integrate

@openjdk
Copy link

openjdk bot commented Jan 19, 2022

Going to push as commit 39b1d75.
Since your change was applied there have been 65 commits pushed to the master branch:

  • 5af7f25: 8274811: Remove superfluous use of boxing in java.base
  • 44fe958: 6465404: some problems in CellEditor related API docs
  • b0496b0: 8279970: two AppCDS tests fail after JDK-8261455
  • 4eb4f94: 8279956: Useless method Scheduling::ComputeLocalLatenciesForward()
  • 4f4da3b: 8275318: loaded_classes_do may see ArrayKlass before InstanceKlass is loaded
  • 3a421e4: 8280122: SupportedGroupsExtension should output "named groups" rather than "versions"
  • 1a20628: 8248404: AArch64: Remove uses of long and unsigned long
  • 46fd683: 8176567: nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10
  • e314a4c: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes
  • bdfa15d: 8250801: Add clhsdb "threadcontext" command
  • ... and 55 more: https://git.openjdk.java.net/jdk/compare/965c64bca713446e7e513170aa9138a8a5eec5de...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Jan 19, 2022
@openjdk openjdk bot closed this Jan 19, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 19, 2022
@openjdk
Copy link

openjdk bot commented Jan 19, 2022

@tstuefe Pushed as commit 39b1d75.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-runtime hotspot-runtime-dev@openjdk.org integrated Pull request has been integrated
4 participants