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-8301749: Tracking malloc pooled memory size #12455

Closed
wants to merge 10 commits into from

Conversation

jdksjolen
Copy link
Contributor

@jdksjolen jdksjolen commented Feb 7, 2023

This PR implements os::malloc_info by calling into glibc's malloc_info and provides a JCmd for asking the JVM to call malloc_info and print out the results. The user can make an informed decision regarding heap trimming by parsing the output of the JCmd. I wanted to avoid parsing the XML inside of the JVM , as this functionality may turn out to be "good enough". A future enhancement would be for the JVM to make this informed decision by parsing the output. Another may be to present this with other data, for example in NMT.

@tstuefe, I think you'd be interested in this PR as it builds upon your trim_native_heap functionality.

I'm using weak symbols (as per ELF) in order to compile this for both GLibc and Musl.

The original bug description is this:

Memory not allocated via NMT and uncommitted memory contributes to a discrepancy between NMT and RSS.
It can be hard to distinguish between these cases.
If the VM can determine the amount of pooled memory by malloc it would help with both determining if a trim_native_memory is needed, or there are some allocations happening outside of NMT.

It would be good if the VM can summarize the malloc pooled memory by using e.g. malloc_info(3).

We can thus more precise account for RSS value.


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
  • Change requires CSR request JDK-8302128 to be approved

Issues

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/12455/head:pull/12455
$ git checkout pull/12455

Update a local copy of the PR:
$ git checkout pull/12455
$ git pull https://git.openjdk.org/jdk pull/12455/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 12455

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/12455.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Feb 7, 2023

👋 Welcome back jsjolen! 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 openjdk bot added the rfr Pull request is ready for review label Feb 7, 2023
@openjdk
Copy link

openjdk bot commented Feb 7, 2023

@jdksjolen 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 Feb 7, 2023
@jdksjolen
Copy link
Contributor Author

I'm opening this PR as a suggested change. I'm not strongly attached to the idea that it must be a JCmd, or that we must simply return the info as it is. I am only strongly attached to the idea that the user should have an easy way of receiving the information that malloc_info offers. If anyone has any suggestions, please share them!

@mlbridge
Copy link

mlbridge bot commented Feb 7, 2023

Webrevs

@poonamparhar
Copy link
Member

@jdksjolen would be good to share the output of this command. Would give an idea to the reviewers as to what information gets printed with this command.

@robehn
Copy link
Contributor

robehn commented Feb 7, 2023

I'm wondering if we should try to warn in the case when user have preloaded a thrid party malloc that don't have malloc_info. But when we load libc that symbol will find a target.
If it's not to much trouble it would be pretty nice if we could return some output to the user indicating this.
Since there a few ways to high-jack malloc maybe it's hard to figure out and argubly if the user preloaded something he should be aware of it, but maybe not aware if it contains malloc_info or not.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

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

General idea is fine - thanks for implementing.

There is unnecessary ifdef usage, and also a query about the existence check, below.

This needs a jcmd documentation update - closed MR to update closed/src/jdk.jcmd/share/man/jcmd.md and then include the updated jcmd.1 manpage file here.

#include <malloc.h>

void MallocInfoDcmd::execute(DCmdSource source, TRAPS) {
#ifdef LINUX
Copy link
Member

Choose a reason for hiding this comment

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

This is a linux-only file. ???

Copy link
Member

Choose a reason for hiding this comment

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

Yes, this is all Linux. Instead, guard with GLIBC, and print in the else branch something like "not a glibc platform".

@@ -217,6 +220,13 @@ julong os::available_memory() {
return Linux::available_memory();
}

int os::Linux::malloc_info(FILE* stream) {
if (::malloc_info) {
Copy link
Member

Choose a reason for hiding this comment

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

This looks strange as an existence check for a library function. At build time what does this get compiled into such that it runtime it can determine whether malloc_info exists or not ??

(also style rules say no implicit booleans so check against nullptr or 0).

Copy link
Member

Choose a reason for hiding this comment

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

I agree, this looks weird. Please do as the Romans do (in this case, as we do with mallinfo/mallinfo2()). Just follow the breadcrumbs.

Additionally, I would put this alongside os::Linux::get_mallinfo and guard it with ifdef GLIBC. You don't need this on muslc.

Copy link
Member

@tstuefe tstuefe left a comment

Choose a reason for hiding this comment

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

@jdksjolen,

interesting. I considered malloc_info() too, but did not feel like parsing XML.

Generally, I would prefer if you keep it closer to what os::get_mallinf() is doing:

  • only define and call that API for ifdef GLIBC
  • resolve the traditional way via function pointers (see our mallinf()/mallinf2() wrappers)
  • have the dcmd execute functions guarded with GLIBC, and an else branch saying its not glibc

This also needs tests. See existing test for trim_native_heap. I would also like a test for muslc to test the stub functionality (its missing from TrimLibcHeapTest.java, which I will add).

// Calls out to GNU extension malloc_info if available
// otherwise does nothing and returns 0.
static int malloc_info(FILE* stream);

Copy link
Member

Choose a reason for hiding this comment

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

Could you put this at the end of the file, alongside os::get_mallinfo(), and within its ifdef GLIBC boundaries?

#ifdef LINUX
char* buf;
size_t size;
ALLOW_C_FUNCTION(::open_memstream, FILE* stream = ::open_memstream(&buf, &size);)
Copy link
Member

Choose a reason for hiding this comment

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

I wondered how open_memstream communicates buffer growth (which may come with re-location). Then I realized that it just modifies the buffer start address the caller gives it in-place. What a weird API :)

You should handle error returns from open_memstream.

@@ -217,6 +220,13 @@ julong os::available_memory() {
return Linux::available_memory();
}

int os::Linux::malloc_info(FILE* stream) {
if (::malloc_info) {
Copy link
Member

Choose a reason for hiding this comment

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

I agree, this looks weird. Please do as the Romans do (in this case, as we do with mallinfo/mallinfo2()). Just follow the breadcrumbs.

Additionally, I would put this alongside os::Linux::get_mallinfo and guard it with ifdef GLIBC. You don't need this on muslc.

char* buf;
size_t size;
ALLOW_C_FUNCTION(::open_memstream, FILE* stream = ::open_memstream(&buf, &size);)
if (!os::Linux::malloc_info(stream)) {
Copy link
Member

Choose a reason for hiding this comment

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

Style nit, can you change this to if (os::Linux::malloc_info(stream) == 0) ? Using ! it reads like the failure branch.

Copy link
Member

Choose a reason for hiding this comment

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

Yes - again no implicit booleans

*/

#include "precompiled.hpp"
#include "runtime/os.inline.hpp"
Copy link
Member

Choose a reason for hiding this comment

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

why this? why not os_linux.hpp?

#include <malloc.h>

void MallocInfoDcmd::execute(DCmdSource source, TRAPS) {
#ifdef LINUX
Copy link
Member

Choose a reason for hiding this comment

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

Yes, this is all Linux. Instead, guard with GLIBC, and print in the else branch something like "not a glibc platform".

#include "precompiled.hpp"
#include "runtime/os.inline.hpp"
#include "mallocInfoDcmd.hpp"
#include "utilities/debug.hpp"
Copy link
Member

Choose a reason for hiding this comment

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

What do you use from debug.hpp?

public:
MallocInfoDcmd(outputStream* output, bool heap) : DCmd(output, heap) {}
static const char* name() {
return "System.malloc_info";
Copy link
Member

Choose a reason for hiding this comment

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

Nit, since the other one is called trim_native_heap, why not "native_heap_info"?

@@ -114,6 +114,9 @@
# include <malloc.h>
#endif

// Forward (re-)declare malloc_info in order to support Alpine Linux.
int __attribute__((weak)) malloc_info(int options, FILE *stream);
Copy link
Member

Choose a reason for hiding this comment

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

Not needed if you do it like os::get_mallinfo() and dlsym the API as proposed.

if (::malloc_info) {
return ::malloc_info(0, stream);
}
return 0;
Copy link
Member

Choose a reason for hiding this comment

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

return -1.

You aim to mimic the malloc_info() API at os:: level, so you should return -1 in case malloc_info failed, including failure do to resolving issues.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

return -1.

You aim to mimic the malloc_info() API at os:: level, so you should return -1 in case malloc_info failed, including failure do to resolving issues.

Wouldn't that lead to a caller not knowing whether malloc_info itself failed or if our wrapper failed? malloc_info also sets errno. I think it's better if we don't imitate malloc_info, by returning -2 if malloc_info is missing, to distinguish the different states.

Copy link
Member

Choose a reason for hiding this comment

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

return -1.
You aim to mimic the malloc_info() API at os:: level, so you should return -1 in case malloc_info failed, including failure do to resolving issues.

Wouldn't that lead to a caller not knowing whether malloc_info itself failed or if our wrapper failed?

Why would that matter?

malloc_info also sets errno. I think it's better if we don't imitate malloc_info, by returning -2 if malloc_info is missing, to distinguish the different states.

We kind of follow this style in a lot of the wrappers we have in os::. As it is now, your malloc_info is neither here nor there - looks and mostly behaves like malloc_info, but not completely. I'd either be consistent and return -1, or convert this to a clearly named wrapper function which should return bool.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

return -1.
You aim to mimic the malloc_info() API at os:: level, so you should return -1 in case malloc_info failed, including failure do to resolving issues.

Wouldn't that lead to a caller not knowing whether malloc_info itself failed or if our wrapper failed?

Why would that matter?

This matters when a caller sees -1, reads errno, and then takes an action depending on errno. If it was our wrapper that failed, then this will be a "stale" errno and a faulty action will be taken. This matters in MallocInfoDcmd::execute because we send different error messages depending on whether the wrapper failed or malloc_info(3) failed.

Copy link
Member

Choose a reason for hiding this comment

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

Okay, fair enough. I would have thought the user cannot really do anything about it anyway, but your way is certainly more precise.

@jdksjolen
Copy link
Contributor Author

Hi, here's a new version.

Notable changes:

  1. Moved stuff around, used dlsym() and __GLIBC__ as requested
  2. More error handling
  3. Rename the Jcmd to System.native_heap_info
  4. Added a test

I left source code names with using malloc_info and not native_heap_info.We reference malloc_info(3) in the error messages and in the description and plainly deliver malloc_info(3)'s XML (and therefore a user must find their schema). Clearly this is not an abstraction over malloc_info(3), so I thought it made sense to keep that clear in the source also.

@dholmes-ora, I'll add a closed PR when everything else has received thumbs up here.

@dholmes-ora
Copy link
Member

@dholmes-ora, I'll add a closed PR when everything else has received thumbs up here.

Okay but note you need to integrate the jcmd.1 changes as part of this PR too.

Also (as @vidmik reminded me):

/csr needed

@openjdk openjdk bot added the csr Pull request needs approved CSR before integration label Feb 8, 2023
@openjdk
Copy link

openjdk bot commented Feb 8, 2023

@dholmes-ora has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@jdksjolen please create a CSR request for issue JDK-8301749 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

Copy link
Member

@tstuefe tstuefe left a comment

Choose a reason for hiding this comment

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

Small nits remain, otherwise fine.

size_t size;
ALLOW_C_FUNCTION(::open_memstream, FILE* stream = ::open_memstream(&buf, &size);)
if (stream == nullptr) {
_output->print("Error: Could not call malloc_info(3)");
Copy link
Member

Choose a reason for hiding this comment

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

end with a newline? or does the caller take care of that? (same below, and the musl path)

int err = os::Linux::malloc_info(stream);
if (err == 0) {
ALLOW_C_FUNCTION(::fflush, fflush(stream);)
_output->print_raw(buf);
Copy link
Member

Choose a reason for hiding this comment

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

indentation

ALLOW_C_FUNCTION(::fclose, ::fclose(stream);)
ALLOW_C_FUNCTION(::free, ::free(buf);)
#else
_output->print(malloc_info_unavailable);
Copy link
Member

Choose a reason for hiding this comment

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

intendation

OutputAnalyzer output = executor.execute("System.native_heap_info");
output.reportDiagnosticSummary();
output.shouldNotMatch(".*Error.*");
output.shouldMatch(".*<malloc version=.*");
Copy link
Member

Choose a reason for hiding this comment

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

small nit, you could probably get by with shouldContain here to save some cycles.

public class MallocInfoTest {
public void run(CommandExecutor executor) {
OutputAnalyzer output = executor.execute("System.native_heap_info");
output.reportDiagnosticSummary();
Copy link
Member

Choose a reason for hiding this comment

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

Do this after the other checks, else on error you will get the report twice.

Copy link
Member

Choose a reason for hiding this comment

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

Just to clarify something in relation to a comment from @tstuefe that I now can't find. It can be useful to show the information even if the test passes, so that, for example, we can go and look at test results and see the kind of data that malloc_info is showing us. I often find myself adding this to tests because they swallow the interesting output even though the test passes (sometimes for the wrong reason!).

public void run(CommandExecutor executor) {
OutputAnalyzer output = executor.execute("System.native_heap_info");
output.reportDiagnosticSummary();
output.shouldNotMatch(".*Error.*");
Copy link
Member

Choose a reason for hiding this comment

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

Can you test exitValue instead of parsing for an error?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think so. Looking at the DCmd class, there seems to be no support of specifying exit value.


void MallocInfoDcmd::execute(DCmdSource source, TRAPS) {
#ifdef __GLIBC__
char* buf;
size_t size;
ALLOW_C_FUNCTION(::open_memstream, FILE* stream = ::open_memstream(&buf, &size);)
if (stream == nullptr) {
_output->print("Error: Could not call malloc_info(3)");
_output->print("Error: Could not call malloc_info(3)\n");
Copy link
Member

Choose a reason for hiding this comment

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

Why not print_cr() ?

} else if (err == -1) {
_output->print("Error: %s", os::strerror(errno));
_output->print("Error: %s\n", os::strerror(errno));
Copy link
Member

Choose a reason for hiding this comment

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

print_cr() ?

return;
}

int err = os::Linux::malloc_info(stream);
if (err == 0) {
ALLOW_C_FUNCTION(::fflush, fflush(stream);)
_output->print_raw(buf);
_output->print_raw(buf);
Copy link
Member

Choose a reason for hiding this comment

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

Append newline (_output->cr())

@dholmes-ora
Copy link
Member

Oh, certainly. But its even more useful the other way around, if the test fails.

@tstuefe if a check fails then reportDiagnosticSummary is already called. E.g.

   public OutputAnalyzer shouldContain(String expectedString) {
        String stdout = getStdout();
        String stderr = getStderr();
        if (!stdout.contains(expectedString) && !stderr.contains(expectedString)) {
            reportDiagnosticSummary();
            throw new RuntimeException("'" + expectedString + "' missing from stdout/stderr");
        }

@mlbridge
Copy link

mlbridge bot commented Feb 10, 2023

Mailing list message from Thomas Stüfe on hotspot-runtime-dev:

On Fri, Feb 10, 2023 at 2:23 AM David Holmes <dholmes at openjdk.org> wrote:

On Thu, 9 Feb 2023 06:15:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

Johan Sj?len has updated the pull request incrementally with four
additional commits since the last revision:

- Fix the test
- Note man section
- Add test
- Reimplement malloc_info as requested

test/hotspot/jtreg/serviceability/dcmd/vm/MallocInfoTest.java line 43:

41: public void run(CommandExecutor executor) {
42: OutputAnalyzer output =
executor.execute("System.native_heap_info");
43: output.reportDiagnosticSummary();

Do this after the other checks, else on error you will get the report
twice.

Just to clarify something in relation to a comment from @tstuefe that I
now can't find. It can be useful to show the information even if the test
passes, so that, for example, we can go and look at test results and see
the kind of data that malloc_info is showing us. I often find myself adding
this to tests because they swallow the interesting output even though the
test passes (sometimes for the wrong reason!).

Oh, certainly. But its even more useful the other way around, if the test
fails. My concern was (and weirdly enough I cannot find my own comment now)
that if you place reportDiagnosticSummary() after the shouldContain, you
won't see anything but the "should match" error. I always place the
reportDiagnosticSummary right at the beginning for that reason.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20230210/68a8bd52/attachment.htm>

@jdksjolen
Copy link
Contributor Author

Hi,

I've updated the man page and done the \n -> cr conversion also. Please have a look :).

Copy link
Member

@tstuefe tstuefe left a comment

Choose a reason for hiding this comment

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

Looks good, apart from a missing newline in the musl path.

Did you test with musl?

ALLOW_C_FUNCTION(::fclose, ::fclose(stream);)
ALLOW_C_FUNCTION(::free, ::free(buf);)
#else
_output->print(malloc_info_unavailable);
Copy link
Member

Choose a reason for hiding this comment

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

Misses a cr

@@ -35,7 +35,7 @@
. ftr VB CB
. ftr VBI CBI
.\}
.TH "JCMD" "1" "2023" "JDK 21-ea" "JDK Commands"
Copy link
Member

Choose a reason for hiding this comment

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

Sorry my bad I gave you the wrong command to use to generate this. It should have been VERSION_SHORT=21-ea

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No worries, I'll just revert the change.

@jdksjolen
Copy link
Contributor Author

Looks good, apart from a missing newline in the musl path.

Did you test with musl?

I have not tested with musl. I'm attempting to cross-build but no success so far :). If you've got a working musl build then I'd be very thankful if you could test these changes.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

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

Nothing further from me. Looks good. Thanks.

@tstuefe
Copy link
Member

tstuefe commented Feb 16, 2023

Looks good, apart from a missing newline in the musl path.
Did you test with musl?

I have not tested with musl. I'm attempting to cross-build but no success so far :). If you've got a working musl build then I'd be very thankful if you could test these changes.

I'll give it a spin on my alpine box.

@tstuefe
Copy link
Member

tstuefe commented Feb 16, 2023

Hi @jdksjolen, I tested musl and it works.

Please see suggested change to add regression testing for musl:

tstuefe@130d68b

Cheers, Thomas

@jdksjolen
Copy link
Contributor Author

Hi @jdksjolen, I tested musl and it works.

Please see suggested change to add regression testing for musl:

tstuefe@130d68b

Cheers, Thomas

Suggested changes looks good, I applied them. Thanks for testing this out.

Cheers

Copy link
Member

@tstuefe tstuefe left a comment

Choose a reason for hiding this comment

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

LGTM

@openjdk openjdk bot removed the csr Pull request needs approved CSR before integration label Feb 17, 2023
@openjdk
Copy link

openjdk bot commented Feb 17, 2023

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

8301749: Tracking malloc pooled memory size

Reviewed-by: dholmes, stuefe

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

  • a917fb3: 7033677: potential cast error in MemberEnter
  • 6120319: 8302226: failure_handler native.core should wait for coredump to finish
  • fef3eab: 8302734: Parallel: Remove unused LGRPSpace::_invalid_region
  • ea5bfea: 8302661: Parallel: Remove PSVirtualSpace::is_aligned
  • edf238b: 8302635: Race condition in HttpBodySubscriberWrapper when cancelling request
  • cd77fcf: 8290822: C2: assert in PhaseIdealLoop::do_unroll() is subject to undefined behavior
  • 57c9bc3: 8302335: IGV: Bytecode not showing
  • 57fde75: 8302113: Improve CRC32 intrinsic with crypto pmull on AArch64
  • b8c9d6c: 8302158: PPC: test/jdk/jdk/internal/vm/Continuation/Fuzz.java: AssertionError: res: false shouldPin: false
  • dc55a7f: 8302202: Incorrect desugaring of null-allowed nested patterns
  • ... and 175 more: https://git.openjdk.org/jdk/compare/716f1df609e7f0aa7b3b9383d23dde5c71017d02...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 Pull request is ready to be integrated label Feb 17, 2023
@jdksjolen
Copy link
Contributor Author

Passes tier1.

/integrate

@openjdk
Copy link

openjdk bot commented Feb 20, 2023

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

  • 6ac5e05: 8302068: Serial: Refactor oop closures used in Young GC
  • 71cf7c4: 8302518: Add missing Op_RoundDoubleMode in VectorNode::vector_operands()
  • 98716e2: 8302709: Remove explicit remembered set verification in G1
  • 303c61f: 8302776: RISC-V: Fix typo CSR_INSTERT to CSR_INSTRET
  • 7c40c8a: 8302312: Make ParGCRareEvent_lock G1 specific
  • 593bec6: 8302122: Parallelize TLAB retirement in prologue in G1
  • e971f90: 8302206: Factor out duplicate G1VerificationClosure
  • eaae0ba: 8302215: G1: Last-ditch Full GC should do serial compaction for tail regions in per thread compaction points.
  • 7e08275: 8302668: [TESTBUG] Tests require feature sse4_1 which does not exist, should be sse4.1
  • 5c0f50b: 8295979: [IR Framework] Improve IR matching warning
  • ... and 199 more: https://git.openjdk.org/jdk/compare/716f1df609e7f0aa7b3b9383d23dde5c71017d02...master

Your commit was automatically rebased without conflicts.

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

openjdk bot commented Feb 20, 2023

@jdksjolen Pushed as commit b5a7426.

💡 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
5 participants