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

8191786: Thread-SMR hash table size should be dynamic #4168

Closed
wants to merge 3 commits into from

Conversation

dcubed-ojdk
Copy link
Member

@dcubed-ojdk dcubed-ojdk commented May 24, 2021

Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable
so that a variable sized hash table is used instead of a fixed size hash table (1031 elements).
Also refactor common hash table size calculation code into static hash_table_size()
function and call it from both places.

Test with Mach5 Tier[1-7] testing.


Progress

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

Issue

  • JDK-8191786: Thread-SMR hash table size should be dynamic

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4168

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

Using diff file

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

@bridgekeeper
Copy link

bridgekeeper bot commented May 24, 2021

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

@dcubed-ojdk
Copy link
Member Author

dcubed-ojdk commented May 24, 2021

/label add hotspot-runtime

@coleenp, @fisk, @robehn and @pchilano - This Thread-SMR fix should be of
interest to you folks. Please chime in on this PR if you have the time.

@dcubed-ojdk dcubed-ojdk marked this pull request as ready for review May 24, 2021
@openjdk openjdk bot added rfr hotspot-runtime labels May 24, 2021
@openjdk
Copy link

openjdk bot commented May 24, 2021

@dcubed-ojdk
The hotspot-runtime label was successfully added.

@mlbridge
Copy link

mlbridge bot commented May 24, 2021

Webrevs

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Hi Dan,

What is the motivation behind this? What do we see happen with the current HT if we have too many threads? What will happen with the new HT when it has to resize - will we see a pause while that happens?

The mechanics of the change seem okay. A couple of queries on ergonomics choices.

Thanks,
David

//
// Undefined symbols for architecture x86_64:
// "BasicHashtable<(MEMFLAGS)2>::free_buckets()", referenced from:
// ThreadsSMRSupport::free_list(ThreadsList*) in threadSMR.o
// ThreadsSMRSupport::is_a_protected_JavaThread(JavaThread*) in threadSMR.o
// "BasicHashtable<(MEMFLAGS)2>::new_entry(unsigned int)", referenced from:
// KVHashtable<void*, bool, (MEMFLAGS)2, &(unsigned int primitive_hash<void*>(void* const&)), &(bool primitive_equals<void*>(void* const&, void* const&))>::add_if_absent(void*, bool, bool*) in threadSMR.o
//
Copy link
Member

@dholmes-ora dholmes-ora May 25, 2021

Choose a reason for hiding this comment

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

We don't need these details in the comment.

Copy link
Member Author

@dcubed-ojdk dcubed-ojdk May 25, 2021

Choose a reason for hiding this comment

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

True, but they served their purpose! I'm going to check out the fix
that @robehn posted about how to get past this compilation issue.

Copy link
Contributor

@coleenp coleenp May 25, 2021

Choose a reason for hiding this comment

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

I don't think you should have these comments either. They don't really help me understand why you get this compilation error. It seems like a TODO. Maybe the mtThread instantiation is missing from hashtable.cpp?

// Hash table size should be first power of two higher than twice the
// length of the ThreadsList
Copy link
Member

@dholmes-ora dholmes-ora May 25, 2021

Choose a reason for hiding this comment

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

What is the basis for this? Seems reasonable for small numbers of threads but excessive for large numbers.

Copy link
Member Author

@dcubed-ojdk dcubed-ojdk May 25, 2021

Choose a reason for hiding this comment

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

This is where we need @fisk. This comment and the associated code was
written by @fisk in the early days of the Thread-SMR project. So we need
Erik to go spelunking in the recesses of his memory for why he sized things
this way...

Also, I think the comment is a bit wrong and doesn't match the code below.

Copy link
Contributor

@coleenp coleenp May 25, 2021

Choose a reason for hiding this comment

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

The theory in the code for KVHashtable or BasicHashtable is that it works better for prime numbers. It'll resize to other prime numbers if needed. I assume starting with 1007 should work fine, if the number of entries matches the number of threads.

const int _small_table_sizes[] = { 107, 1009, 2017, 4049, 5051, 10103, 20201, 40423 } ;
These are the resizing sizes in hashtable.cpp.

Edit: You could use this table to choose an initial size based on your current number of threads.

Copy link
Contributor

@fisk fisk May 25, 2021

Choose a reason for hiding this comment

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

This is where we need @fisk. This comment and the associated code was

written by @fisk in the early days of the Thread-SMR project. So we need

Erik to go spelunking in the recesses of his memory for why he sized things

this way...

Also, I think the comment is a bit wrong and doesn't match the code below.

I have a habit of sizing hash tables in this way to achieve the following:

  • The power of two table size means you can map to a bucket using hash & (size - 1), instead of the much more expensive hash % size. Modulo is several orders of magnitude more expensive to execute.
  • Make sure the average number of entries per bucket is not exceeding 1.

Having said that, the first of those two reasons no longer applies; the more generic table logic we use nowadays uses modulo based bucket mapping I think. I probably had a more manually crafted table earlier where I used that property. It was quite a while ago, so I don't remember what happened with that. If I had to guess, I'd think @coleenp might have encouraged me to not implement yet another hash table, as we already have too many in general.

// length of the ThreadsList
static int hash_table_size() {
ThreadsList* threads = ThreadsSMRSupport::get_java_thread_list();
int hash_table_size = MIN2((int)threads->length(), 32) << 1;
Copy link
Member

@dholmes-ora dholmes-ora May 25, 2021

Choose a reason for hiding this comment

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

Doesn't this start things off a bit small. If the old size was 1031 why not start in that area?

Copy link
Member Author

@dcubed-ojdk dcubed-ojdk May 25, 2021

Choose a reason for hiding this comment

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

We need @fisk to time in here with his rationale from the beginning of the Thread-SMR project.

The 1031 came from me and I stole it from some other fixed hash table size in the VM.

Someone please correct me if I'm wrong, but doesn't this hash_table_size value max out
at 64? MIN2((int)threads->length(), 32) => 32 when there are more than 32 threads
and 32 << 1 => 64.

Yeah, we really need @fisk to chime in here.

Also, don't forget that these hash_tables are very, very short lived
since they only exist while we are gathering either hazard ptrs or
JavaThread* protected by hazard ptrs.

Copy link
Contributor

@coleenp coleenp May 25, 2021

Choose a reason for hiding this comment

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

Yes, 32 doesn't seem right.

Copy link
Contributor

@fisk fisk May 25, 2021

Choose a reason for hiding this comment

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

We need @fisk to time in here with his rationale from the beginning of the Thread-SMR project.

The 1031 came from me and I stole it from some other fixed hash table size in the VM.

Someone please correct me if I'm wrong, but doesn't this hash_table_size value max out

at 64? MIN2((int)threads->length(), 32) => 32 when there are more than 32 threads

and 32 << 1 => 64.

Yeah, we really need @fisk to chime in here.

Also, don't forget that these hash_tables are very, very short lived

since they only exist while we are gathering either hazard ptrs or

JavaThread* protected by hazard ptrs.

I don't recognize the arbitrary 32 limit. If I did indeed write that (I have no recollection), then the only reason for it that I can think of is that hazard pointers are (or were?) very infrequent to encounter and that most of the time, we end up adding no entries at all to the table. And that it would be somehow wasteful to allocate large tables only to not put anything into it.

But yeah, wouldn't mind getting rid of this arbitrary heuristic limit. I don't think it matters today.

Copy link
Member

@dholmes-ora dholmes-ora May 25, 2021

Choose a reason for hiding this comment

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

So the "dynamic" aspect of this is not a long-lived table that needs to grow/shrink, but simply that we want to size each short-lived table more appropriately rather than all being sized at 1031.

Very unclear what potential performance implication of this change could be.

@robehn
Copy link
Contributor

robehn commented May 25, 2021

Hi Dan, it looks like someone confused x-macros and templates. The issue is that there is code in the CPP file which requires expansion, so when compiling the CPP file it must know all templates instances.... the CPP should removed!

This is the temporary fix until we have removed that CPP file.

diff --git a/src/hotspot/share/runtime/threadSMR.cpp b/src/hotspot/share/runtime/threadSMR.cpp
index f08320a9a95..c1daf26e7da 100644
--- a/src/hotspot/share/runtime/threadSMR.cpp
+++ b/src/hotspot/share/runtime/threadSMR.cpp
@@ -195,13 +195,3 @@ class ThreadScanHashtable : public CHeapObj<mtThread> {
   int _table_size;
-  // Note: I want this to be mtThread, but that causes linkage errors:
-  //
-  //   Undefined symbols for architecture x86_64:
-  //   "BasicHashtable<(MEMFLAGS)2>::free_buckets()", referenced from:
-  //   ThreadsSMRSupport::free_list(ThreadsList*) in threadSMR.o
-  //   ThreadsSMRSupport::is_a_protected_JavaThread(JavaThread*) in threadSMR.o
-  //   "BasicHashtable<(MEMFLAGS)2>::new_entry(unsigned int)", referenced from:
-  //   KVHashtable<void*, bool, (MEMFLAGS)2, &(unsigned int primitive_hash<void*>(void* const&)), &(bool primitive_equals<void*>(void* const&, void* const&))>::add_if_absent(void*, bool, bool*) in threadSMR.o
-  //
-  // so I'm using mtInternal instead.
-  KVHashtable<void *, bool, mtInternal, &ThreadScanHashtable::ptr_hash,
+  KVHashtable<void *, bool, mtThread, &ThreadScanHashtable::ptr_hash,
                             &ThreadScanHashtable::ptr_equals> _ptrs;
diff --git a/src/hotspot/share/utilities/hashtable.cpp b/src/hotspot/share/utilities/hashtable.cpp
index c3c62e4c20b..0b0d3de72af 100644
--- a/src/hotspot/share/utilities/hashtable.cpp
+++ b/src/hotspot/share/utilities/hashtable.cpp
@@ -281,2 +281,3 @@ template class BasicHashtable<mtTracing>;
 template class BasicHashtable<mtServiceability>;
+template class BasicHashtable<mtThread>;

Thanks, Robbin

robehn
robehn approved these changes May 25, 2021
@openjdk
Copy link

openjdk bot commented May 25, 2021

@dcubed-ojdk 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:

8191786: Thread-SMR hash table size should be dynamic

Reviewed-by: dholmes, rehn, coleenp, eosterlund

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

  • 85f6165: 8267817: [TEST] Remove unnecessary init in test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench:setup
  • 7278f56: 8267800: Remove the '_dirty' set in BCEscapeAnalyzer
  • bfa46f0: 8252476: as_Worker_thread() doesn't check what it intends
  • 37bc4e2: 8263635: Add --servername option to jhsdb debugd
  • 6ffa3e6: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported
  • 1899f02: 8267805: Add UseVtableBasedCHA to the list of JVM flags known to jtreg
  • 0fc7c8d: 8267751: (test) jtreg.SkippedException has no serial VersionUID
  • a859d87: 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2 AArch64
  • e630235: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals
  • 8c4719a: 8265248: Implementation Specific Properties: change prefix, plus add existing properties
  • ... and 57 more: https://git.openjdk.java.net/jdk/compare/fe333431c8c0f089e4fd55bf10903e1fba7fc6c4...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 25, 2021
@dcubed-ojdk
Copy link
Member Author

dcubed-ojdk commented May 25, 2021

What is the motivation behind this?

Finishing code that was left incomplete by the Thread-SMR project. We either
get rid of the hash_table_size calculations (from two places) in the base code
or we switch to a Hashtable that supports specifying a size at runtime instead
of compile time.

What do we see happen with the current HT if we have too many threads?

We haven't seen any problems with the current code. I'm just cleaning up this
long standing piece of work.

What will happen with the new HT when it has to resize - will we see a
pause while that happens?

These Thread-SMR hash tables don't resize. They are created and live for
a very short time. They contain either hazard ptrs or they contain JavaThread*
that are protected by hazard ptrs.

ThreadsSMRSupport::free_list() creates a ThreadScanHashtable of the
current hazard ptrs (there typically are not very many of these).

ThreadsSMRSupport::is_a_protected_JavaThread() creates a
ThreadScanHashtable of JavaThread* that are protected by the
current hazard ptr in use by the system.

Both of these ThreadScanHashtable objects only live as long as the
function that created them, i.e., not long.

@dcubed-ojdk
Copy link
Member Author

dcubed-ojdk commented May 25, 2021

@robehn - Thanks for fix. I'll take it for a spin right now.

@dcubed-ojdk
Copy link
Member Author

dcubed-ojdk commented May 25, 2021

@dholmes-ora and @robehn - Thanks for the reviews!

Copy link
Contributor

@coleenp coleenp left a comment

I think you updated it to fix the mtThread problem, while I was reviewing this.

//
// Undefined symbols for architecture x86_64:
// "BasicHashtable<(MEMFLAGS)2>::free_buckets()", referenced from:
// ThreadsSMRSupport::free_list(ThreadsList*) in threadSMR.o
// ThreadsSMRSupport::is_a_protected_JavaThread(JavaThread*) in threadSMR.o
// "BasicHashtable<(MEMFLAGS)2>::new_entry(unsigned int)", referenced from:
// KVHashtable<void*, bool, (MEMFLAGS)2, &(unsigned int primitive_hash<void*>(void* const&)), &(bool primitive_equals<void*>(void* const&, void* const&))>::add_if_absent(void*, bool, bool*) in threadSMR.o
//
Copy link
Contributor

@coleenp coleenp May 25, 2021

Choose a reason for hiding this comment

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

I don't think you should have these comments either. They don't really help me understand why you get this compilation error. It seems like a TODO. Maybe the mtThread instantiation is missing from hashtable.cpp?

// Hash table size should be first power of two higher than twice the
// length of the ThreadsList
Copy link
Contributor

@coleenp coleenp May 25, 2021

Choose a reason for hiding this comment

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

The theory in the code for KVHashtable or BasicHashtable is that it works better for prime numbers. It'll resize to other prime numbers if needed. I assume starting with 1007 should work fine, if the number of entries matches the number of threads.

const int _small_table_sizes[] = { 107, 1009, 2017, 4049, 5051, 10103, 20201, 40423 } ;
These are the resizing sizes in hashtable.cpp.

Edit: You could use this table to choose an initial size based on your current number of threads.

// length of the ThreadsList
static int hash_table_size() {
ThreadsList* threads = ThreadsSMRSupport::get_java_thread_list();
int hash_table_size = MIN2((int)threads->length(), 32) << 1;
Copy link
Contributor

@coleenp coleenp May 25, 2021

Choose a reason for hiding this comment

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

Yes, 32 doesn't seem right.

@dcubed-ojdk
Copy link
Member Author

dcubed-ojdk commented May 25, 2021

@coleenp - Thanks for the review! And sorry for changing the PR while you
were reviewing...

We definitely need to hear from @fisk on this PR... :-)

@dcubed-ojdk
Copy link
Member Author

dcubed-ojdk commented May 25, 2021

BTW, I suspect @fisk's choice of a max hash_table_size of 64 is due to
his hash function:

        static unsigned int ptr_hash(void * const&amp; s1) {
          // 2654435761 = 2^32 * Phi (golden ratio)
          return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u);
        }

Copy link
Contributor

@coleenp coleenp left a comment

I didn't review this very carefully. I don't see where you free the hashtables.

@dcubed-ojdk
Copy link
Member Author

dcubed-ojdk commented May 25, 2021

Here's where they are allocated and deleted:

void ThreadsSMRSupport::free_list(ThreadsList* threads) {
<snip>
  ThreadScanHashtable *scan_table = new ThreadScanHashtable(hash_table_size());
<snip>
  delete scan_table;
}

bool ThreadsSMRSupport::is_a_protected_JavaThread(JavaThread *thread) {
<snip>
  ThreadScanHashtable *scan_table = new ThreadScanHashtable(hash_table_size());
<snip>
  delete scan_table;
  return thread_is_protected;
}


~ThreadScanHashtable() { delete _ptrs; }
~ThreadScanHashtable() {
log_trace(thread, smr)("tid=" UINTX_FORMAT ": deallocate ThreadScanHashtable(%d) at " INTPTR_FORMAT, os::current_thread_id(), _table_size, p2i(this));
Copy link
Contributor

@coleenp coleenp May 25, 2021

Choose a reason for hiding this comment

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

For a CHeap hashtable, I believe this should do this (or have KVHash have an API to delete all the entries).
Dictionary::~Dictionary() {
DictionaryEntry* probe = NULL;
for (int index = 0; index < table_size(); index++) {
for (DictionaryEntry** p = bucket_addr(index); *p != NULL; ) {
probe = *p;
*p = probe->next();
free_entry(probe);
}
}
assert(number_of_entries() == 0, "should have removed all entries");
}

Copy link
Contributor

@coleenp coleenp May 25, 2021

Choose a reason for hiding this comment

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

This should be added to KVHashtable because it would be nice to migrate the other hashtables to this nicer API.

Copy link
Contributor

@coleenp coleenp May 25, 2021

Choose a reason for hiding this comment

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

I don't see how the entries in the table are freed (in any of the KVHashtables). Maybe I'm missing something.

Copy link
Member Author

@dcubed-ojdk dcubed-ojdk May 25, 2021

Choose a reason for hiding this comment

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

I'll take a look.

Copy link
Contributor

@coleenp coleenp May 26, 2021

Choose a reason for hiding this comment

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

@mlbridge
Copy link

mlbridge bot commented May 26, 2021

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

Hi Dan,

On 26/05/2021 5:48 am, Daniel D.Daugherty wrote:

On Tue, 25 May 2021 01:10:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

What is the motivation behind this?

Finishing code that was left incomplete by the Thread-SMR project. We either
get rid of the hash_table_size calculations (from two places) in the base code
or we switch to a Hashtable that supports specifying a size at runtime instead
of compile time.

Okay - removing the unused code would be a less disruptive change in
that case.

What do we see happen with the current HT if we have too many threads?

We haven't seen any problems with the current code. I'm just cleaning up this
long standing piece of work.

What will happen with the new HT when it has to resize - will we see a
pause while that happens?

These Thread-SMR hash tables don't resize. They are created and live for
a very short time. They contain either hazard ptrs or they contain JavaThread*
that are protected by hazard ptrs.

ThreadsSMRSupport::free_list() creates a ThreadScanHashtable of the
current hazard ptrs (there typically are not very many of these).

ThreadsSMRSupport::is_a_protected_JavaThread() creates a
ThreadScanHashtable of JavaThread* that are protected by the
current hazard ptr in use by the system.

Both of these ThreadScanHashtable objects only live as long as the
function that created them, i.e., not long.

Okay I get the "dynamic" aspect of this now.

Thanks,
David

1 similar comment
@mlbridge
Copy link

mlbridge bot commented May 26, 2021

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

Hi Dan,

On 26/05/2021 5:48 am, Daniel D.Daugherty wrote:

On Tue, 25 May 2021 01:10:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

What is the motivation behind this?

Finishing code that was left incomplete by the Thread-SMR project. We either
get rid of the hash_table_size calculations (from two places) in the base code
or we switch to a Hashtable that supports specifying a size at runtime instead
of compile time.

Okay - removing the unused code would be a less disruptive change in
that case.

What do we see happen with the current HT if we have too many threads?

We haven't seen any problems with the current code. I'm just cleaning up this
long standing piece of work.

What will happen with the new HT when it has to resize - will we see a
pause while that happens?

These Thread-SMR hash tables don't resize. They are created and live for
a very short time. They contain either hazard ptrs or they contain JavaThread*
that are protected by hazard ptrs.

ThreadsSMRSupport::free_list() creates a ThreadScanHashtable of the
current hazard ptrs (there typically are not very many of these).

ThreadsSMRSupport::is_a_protected_JavaThread() creates a
ThreadScanHashtable of JavaThread* that are protected by the
current hazard ptr in use by the system.

Both of these ThreadScanHashtable objects only live as long as the
function that created them, i.e., not long.

Okay I get the "dynamic" aspect of this now.

Thanks,
David

@dcubed-ojdk
Copy link
Member Author

dcubed-ojdk commented May 26, 2021

@fisk - Thanks for chiming in on this thread.

@coleenp - I tried adding free_entries() support, but I wasn't able to get the code to build. Thanks for filing https://bugs.openjdk.java.net/browse/JDK-8267752 so someone can followup on KVHashtable entry freeing.

@dholmes-ora - Agreed that I have no idea what the performance impact would be and I don't want to take the time to figure that out so I'm going to rewind and go the other route that has been discussed for this bug:

  • remove the unused hash_table_size calculations
  • leave the Thread-SMR hash table at 1031 elements since it has been that way since JDK10-B36 (integrated on 2017.11.24)

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Updated minimalist approach looks good.

Thanks,
David

fisk
fisk approved these changes May 27, 2021
Copy link
Contributor

@fisk fisk left a comment

Looks good.

robehn
robehn approved these changes May 27, 2021
Copy link
Contributor

@coleenp coleenp left a comment

Looks good!

@dcubed-ojdk
Copy link
Member Author

dcubed-ojdk commented May 27, 2021

@dholmes-ora, @fisk, @robehn and @coleenp - Thanks for the re-reviews!

/integrate

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

openjdk bot commented May 27, 2021

@dcubed-ojdk Since your change was applied there have been 72 commits pushed to the master branch:

  • ef368b3: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container
  • 10a6f5d: 8230623: Extract command-line help for -Xlint sub-options to new --help-lint
  • bea4109: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar
  • ec65cf8: 8240347: remove undocumented options from jlink --help message
  • 3623abb: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles
  • 85f6165: 8267817: [TEST] Remove unnecessary init in test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench:setup
  • 7278f56: 8267800: Remove the '_dirty' set in BCEscapeAnalyzer
  • bfa46f0: 8252476: as_Worker_thread() doesn't check what it intends
  • 37bc4e2: 8263635: Add --servername option to jhsdb debugd
  • 6ffa3e6: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported
  • ... and 62 more: https://git.openjdk.java.net/jdk/compare/fe333431c8c0f089e4fd55bf10903e1fba7fc6c4...master

Your commit was automatically rebased without conflicts.

Pushed as commit 23189a1.

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

@dcubed-ojdk dcubed-ojdk deleted the JDK-8191786 branch May 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-runtime integrated
5 participants