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-8263495: Gather liveness info in the mark phase of G1 full gc #2966

Closed
wants to merge 8 commits into from

Conversation

@Hamlin-Li
Copy link

@Hamlin-Li Hamlin-Li commented Mar 12, 2021

Gather liveness info in the mark phase of G1 full gc.

Per-region liveness info in the mark phase of G1 full gc is for several purposes:

JDK-8262068 needs it to determine whether compaction of a region should be skipped
JDK-8258431 for a JFR event that prints live set size estimate

so add this functionality.


Progress

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

Issue

  • JDK-8263495: Gather liveness info in the mark phase of G1 full gc

Reviewers

Contributors

  • Shoubing Ma <mashoubing1@huawei.com>

Download

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

To update a local copy of the PR:
$ git checkout pull/2966
$ git pull https://git.openjdk.java.net/jdk pull/2966/head

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Mar 12, 2021

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

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Mar 12, 2021

@Hamlin-Li The following label will be automatically applied to this pull request:

  • hotspot-gc

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.

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Mar 12, 2021

Loading

@Hamlin-Li
Copy link
Author

@Hamlin-Li Hamlin-Li commented Mar 15, 2021

@tschatzl Hi Thomas, the patch is ready, would you mind to review the patch when available? Thanks.

Loading

Copy link
Contributor

@tschatzl tschatzl left a comment

Other than that, initial review looks good. Thanks for extracting this piece of functionality, which makes the follow-up change likely easier to review.

Loading

for (uint j = 0; j < _heap->max_regions(); j++) {
sum += _live_stats[j]._live_words;
}
_heap->set_used(sum * HeapWordSize);
Copy link
Contributor

@tschatzl tschatzl Mar 15, 2021

Choose a reason for hiding this comment

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

used() is different to live() in that used() contains all space that is not allocatable (or should at least). This includes space lost due to fragmentation or just not compacting it. I think this hunk should be removed at this time until it is required.
Also, this value will be overwritten by the call to rebuild_region_sets in G1FullCollector::prepare_heap_for_mutators() as far as I can tell.

Loading

G1RegionMarkStatsCache _mark_region_cache;
// Number of entries in the per-task stats entry. This seems enough to have a very
// low cache miss rate.
static const uint RegionMarkStatsCacheSize = 1024;
Copy link
Contributor

@tschatzl tschatzl Mar 15, 2021

Choose a reason for hiding this comment

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

Please move this constant to G1RegionMarkStatsCache and reuse in both places where this constant is used instead of duplicating it.

Loading

@@ -74,7 +80,8 @@ class G1FullGCMarker : public CHeapObj<mtGC> {
inline void follow_array(objArrayOop array);
inline void follow_array_chunk(objArrayOop array, int index);
public:
G1FullGCMarker(G1FullCollector* collector, uint worker_id, PreservedMarks* preserved_stack);
G1FullGCMarker(G1FullCollector* collector, uint worker_id,
PreservedMarks* preserved_stack, G1RegionMarkStats* mark_stats);
Copy link
Contributor

@tschatzl tschatzl Mar 15, 2021

Choose a reason for hiding this comment

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

I think it is better at this point to put one argument per line.

Loading

@@ -31,6 +31,7 @@
#include "gc/g1/g1FullGCCompactionPoint.hpp"
#include "gc/g1/g1FullGCMarker.hpp"
#include "gc/g1/g1FullGCOopClosures.inline.hpp"
#include "gc/g1/g1RegionMarkStatsCache.inline.hpp"
Copy link
Contributor

@tschatzl tschatzl Mar 15, 2021

Choose a reason for hiding this comment

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

This should not be needed, the cache is not accessed in this file.

Loading

Copy link
Author

@Hamlin-Li Hamlin-Li Mar 16, 2021

Choose a reason for hiding this comment

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

I thought so at the beginning, but pre-submit test report compilation error on mac and linux x86, so I added these includes.
compilation error log is at: https://github.com/Hamlin-Li/jdk/runs/2095446669?check_suite_focus=true

Loading

Copy link
Contributor

@kstefanj kstefanj Mar 16, 2021

Choose a reason for hiding this comment

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

It complains that mark_object() needs it, so it should be enough to add the include to this file: src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp which is where mark_object() is defined.

Loading

@@ -27,6 +27,7 @@
#include "gc/g1/g1FullCollector.hpp"
#include "gc/g1/g1FullGCMarker.inline.hpp"
#include "gc/g1/g1FullGCOopClosures.inline.hpp"
#include "gc/g1/g1RegionMarkStatsCache.inline.hpp"
Copy link
Contributor

@tschatzl tschatzl Mar 15, 2021

Choose a reason for hiding this comment

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

This file does not seem to use the G1RegionMarkStatsCache so this include seems unnecessary.

Loading

@@ -31,6 +31,7 @@
#include "gc/g1/g1FullGCOopClosures.inline.hpp"
#include "gc/g1/g1FullGCPrepareTask.hpp"
#include "gc/g1/g1HotCardCache.hpp"
#include "gc/g1/g1RegionMarkStatsCache.inline.hpp"
Copy link
Contributor

@tschatzl tschatzl Mar 15, 2021

Choose a reason for hiding this comment

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

Not needed.

Loading

@@ -28,6 +28,7 @@
#include "gc/g1/g1FullGCMarker.hpp"
#include "gc/g1/g1FullGCOopClosures.inline.hpp"
#include "gc/g1/g1FullGCReferenceProcessorExecutor.hpp"
#include "gc/g1/g1RegionMarkStatsCache.inline.hpp"
Copy link
Contributor

@tschatzl tschatzl Mar 15, 2021

Choose a reason for hiding this comment

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

Not needed.

Loading

@@ -27,6 +27,7 @@

#include "gc/g1/g1BlockOffsetTable.hpp"
#include "gc/g1/g1HeapRegionTraceType.hpp"
#include "gc/g1/g1RegionMarkStatsCache.hpp"
Copy link
Contributor

@tschatzl tschatzl Mar 15, 2021

Choose a reason for hiding this comment

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

This file does not use G1RegionMarkStatsCache, so shouldn't need an include.

Loading

Copy link
Author

@Hamlin-Li Hamlin-Li Mar 16, 2021

Choose a reason for hiding this comment

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

Thanks for pointing out.
it compiles successfully on my local env, let's see if it will compile in pre-submit build/test

Loading

Copy link
Contributor

@tschatzl tschatzl Mar 16, 2021

Choose a reason for hiding this comment

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

This typically indicates that the header include is missing elsewhere. One thing that often helps is compiling with configure disabled precompiled headers, ie. --disable-precompiled-headers in configure.

Loading

@@ -44,6 +45,17 @@ G1RegionMarkStatsCache::~G1RegionMarkStatsCache() {
FREE_C_HEAP_ARRAY(G1RegionMarkStatsCacheEntry, _cache);
}

// cache size is equal to or bigger than region size to intialize region_index
void G1RegionMarkStatsCache::initialize() {
Copy link
Contributor

@tschatzl tschatzl Mar 15, 2021

Choose a reason for hiding this comment

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

If the change really wants to avoid the initial cache misses (for regions != 0), please merge this with the existing reset() method. I do not think it makes a difference to have this optimization that exploits the simplicity of G1RegionMarkStatsCacheEntry::hash().
(And if the hash() implementation ever changes, this optimization won't work any more).

If you do so, also add a clear comment why the cache is initialized with these values. The comment

// cache size is equal to or bigger than region size to intialize region_index

seems at least misplaced.

The change could, at the assignment (maybe even add an optional parameter to clear()) state:

// Avoid the initial cache miss and eviction by setting the i'th's cache region_idx to the region_idx due to how the hash is calculated.

Note that resetting to constant values in that loop will likely be folded into a memset, while this loop needs to be translated as is, and may be a lot slower (with 100k+ regions...) in the pause.

In a textbook implementation, G1RegionMarkStatsCacheEntry::clear() should probably set the region index to G1_NO_HRM_INDEX (i.e. (uint)-1) to indicate emptiness so that all initial cache lookups fail (i.e. evict the previous, non-existing value). But then the simple implementation of the G1RegionMarkStatsCache::evict method will access the liveness array out of bounds... (that's probably why the initial region_idx values are zero, not as some sort of optimization - we save some conditional in that method).

Loading

Copy link
Author

@Hamlin-Li Hamlin-Li Mar 16, 2021

Choose a reason for hiding this comment

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

Thanks Thomas, I will merge reset and initialize, and add the comment you suggested.

Loading

Copy link
Author

@Hamlin-Li Hamlin-Li Mar 16, 2021

Choose a reason for hiding this comment

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

BTW, a quick question: is there a limit on the region number in G1?

Loading

Copy link
Contributor

@tschatzl tschatzl Mar 16, 2021

Choose a reason for hiding this comment

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

The limit is 2^32-2, i.e. the range of uint - 1 for that G1_NO_HRM_INDEX which is a special value.

Loading

Copy link
Contributor

@kstefanj kstefanj left a comment

Just a few additional comments to the ones made by Thomas.

Loading

@@ -31,6 +31,7 @@
#include "gc/g1/g1FullGCCompactionPoint.hpp"
#include "gc/g1/g1FullGCMarker.hpp"
#include "gc/g1/g1FullGCOopClosures.inline.hpp"
#include "gc/g1/g1RegionMarkStatsCache.inline.hpp"
Copy link
Contributor

@kstefanj kstefanj Mar 16, 2021

Choose a reason for hiding this comment

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

It complains that mark_object() needs it, so it should be enough to add the include to this file: src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp which is where mark_object() is defined.

Loading

@@ -25,14 +25,16 @@
#include "precompiled.hpp"
#include "classfile/classLoaderData.hpp"
#include "gc/g1/g1FullGCMarker.inline.hpp"
#include "gc/g1/g1RegionMarkStatsCache.inline.hpp"
Copy link
Contributor

@kstefanj kstefanj Mar 16, 2021

Choose a reason for hiding this comment

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

Shouldn't need the inline.hpp here, .hpp should be enough.

Loading

Copy link
Author

@Hamlin-Li Hamlin-Li Mar 16, 2021

Choose a reason for hiding this comment

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

Thanks Stefan.

Loading

Copy link
Contributor

@kstefanj kstefanj left a comment

Starting to look good, just a few more cleanups.

Loading

@@ -30,6 +30,7 @@
#include "gc/g1/g1FullGCMarkTask.hpp"
#include "gc/g1/g1FullGCOopClosures.inline.hpp"
#include "gc/g1/g1FullGCReferenceProcessorExecutor.hpp"
#include "gc/g1/g1RegionMarkStatsCache.inline.hpp"
Copy link
Contributor

@kstefanj kstefanj Mar 16, 2021

Choose a reason for hiding this comment

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

Not needed afaict.

Loading

void flush_mark_region_cache() {
_mark_region_cache.evict_all();
}
Copy link
Contributor

@kstefanj kstefanj Mar 16, 2021

Choose a reason for hiding this comment

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

Please move this definition to the cpp-file.

Loading

@@ -63,6 +63,9 @@ class G1FullGCMarker : public CHeapObj<mtGC> {
G1FollowStackClosure _stack_closure;
CLDToOopClosure _cld_closure;


G1RegionMarkStatsCache _mark_region_cache;
Copy link
Contributor

@kstefanj kstefanj Mar 16, 2021

Choose a reason for hiding this comment

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

Please add the include to this file:
#include "gc/g1/g1RegionMarkStatsCache.hpp"

Loading

Copy link
Author

@Hamlin-Li Hamlin-Li Mar 17, 2021

Choose a reason for hiding this comment

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

Thanks Stefan, Just modified as you suggested.

Loading

@Hamlin-Li
Copy link
Author

@Hamlin-Li Hamlin-Li commented Mar 17, 2021

There are windows build failure, but it seems not related to my patch.

Loading

@Hamlin-Li
Copy link
Author

@Hamlin-Li Hamlin-Li commented Mar 17, 2021

/contributor add Shoubing Ma mashoubing1@huawei.com

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Mar 17, 2021

@Hamlin-Li Could not parse Shoubing Ma mashoubing1@huawei.com as a valid contributor.
Syntax: /contributor (add|remove) [@user | openjdk-user | Full Name <email@address>]. For example:

  • /contributor add @openjdk-bot
  • /contributor add duke
  • /contributor add J. Duke <duke@openjdk.org>

Loading

@kstefanj
Copy link
Contributor

@kstefanj kstefanj commented Mar 17, 2021

Thanks for addressing the comments, I've kicked off some additional functional testing and will do some manual performance testing as well.

Loading

@Hamlin-Li
Copy link
Author

@Hamlin-Li Hamlin-Li commented Mar 17, 2021

/contributor add Shoubing Ma mashoubing1@huawei.com

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Mar 17, 2021

@Hamlin-Li
Contributor Shoubing Ma <mashoubing1@huawei.com> successfully added.

Loading

Copy link
Contributor

@tschatzl tschatzl left a comment

Some additional sweep through the code showed some more minor issues. Sorry for not noticing earlier.

Loading

@@ -60,6 +60,8 @@ void G1FullGCMarkTask::work(uint worker_id) {

// Mark stack is populated, now process and drain it.
marker->complete_marking(collector()->oop_queue_set(), collector()->array_queue_set(), &_terminator);
// flush live bytes to regions
marker->flush_mark_region_cache();
Copy link
Contributor

@tschatzl tschatzl Mar 17, 2021

Choose a reason for hiding this comment

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

Please use mark_stats instead of mark_region in all identifier names. It is kind of jarring to have the class called G1Mark*Stats*Cache, all other related variables also with something containing mark_stats and then to use something else in the instances for this for no discernible reason.

I.e. please rename this method and the member from _mark_region_cache to _mark_stats_cache.

Of course, if you have a reason to do so please tell.

Loading

@@ -60,6 +60,8 @@ void G1FullGCMarkTask::work(uint worker_id) {

// Mark stack is populated, now process and drain it.
marker->complete_marking(collector()->oop_queue_set(), collector()->array_queue_set(), &_terminator);
// flush live bytes to regions
Copy link
Contributor

@tschatzl tschatzl Mar 17, 2021

Choose a reason for hiding this comment

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

Comment containing full sentences should start with upper case like the one before and end with a full stop. Also that comment is probably better placed at the declaration in the .hpp file.

Loading

// Reset liveness of all cache entries to their default values,
// initialize _region_idx to avoid initial cache miss.
Copy link
Contributor

@tschatzl tschatzl Mar 17, 2021

Choose a reason for hiding this comment

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

Comments describing the functionality of a method should be at the declaration. Only implementation details should be added at the definition.

Loading

void clear() {
_region_idx = 0;
void clear(uint idx = 0) {
_region_idx = idx;
Copy link
Contributor

@tschatzl tschatzl Mar 17, 2021

Choose a reason for hiding this comment

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

I unfortunately can't comment on the other method is_clear() here - please remove because it is a) wrong now with that special initialization and b) not used anywhere apparently.

Loading

Copy link
Author

@Hamlin-Li Hamlin-Li Mar 17, 2021

Choose a reason for hiding this comment

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

Thanks for the detailed review.

Loading

@@ -98,6 +98,10 @@ class G1RegionMarkStatsCache {

G1RegionMarkStatsCacheEntry* find_for_add(uint region_idx);
public:
// Number of entries in the per-task stats entry. This seems enough to have a very
Copy link
Contributor

@tschatzl tschatzl Mar 17, 2021

Choose a reason for hiding this comment

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

pre-existing: please add "value" after the "This" to read "This value seems enough to...." (or "The suggested value" or something to that effect.

Loading

@kstefanj
Copy link
Contributor

@kstefanj kstefanj commented Mar 17, 2021

Testing showed that the regression I reported in the other PR is still present for this fix. Same small reproducer can be used:

public class SystemGCLarge {
  public static Object[] holder;
  public static void main(String args[]) {
    holder = new Object[128 * 1024 *1024];
    System.gc();
    System.out.println("Done");
  }
}

I've made a change that eliminates the regression by making sure the cache update is not inlined and by doing so allows for other inlining to be done:
kstefanj@abf54fb

Loading

@Hamlin-Li
Copy link
Author

@Hamlin-Li Hamlin-Li commented Mar 18, 2021

Testing showed that the regression I reported in the other PR is still present for this fix. Same small reproducer can be used:

public class SystemGCLarge {
  public static Object[] holder;
  public static void main(String args[]) {
    holder = new Object[128 * 1024 *1024];
    System.gc();
    System.out.println("Done");
  }
}

I've made a change that eliminates the regression by making sure the cache update is not inlined and by doing so allows for other inlining to be done:
kstefanj@abf54fb

On my local env, it seems make no difference wIth or w/o your patch, for both marking phase and whole full gc pause. But I will apply your patch, Thanks a lot for the benchmarking.

Loading

@kstefanj
Copy link
Contributor

@kstefanj kstefanj commented Mar 18, 2021

On my local env, it seems make no difference wIth or w/o your patch, for both marking phase and whole full gc pause. But I will apply your patch, Thanks a lot for the benchmarking.

What inlining gets done will depend a lot on the build env, so it might be that your build don't experience the same issue. Because you mean that you can't reproduce the regression at all right? Or is the regression present even after my patch?

Loading

@Hamlin-Li
Copy link
Author

@Hamlin-Li Hamlin-Li commented Mar 18, 2021

It's all the same, following data is in the order of master/with/w/o, (I don't "make clean" before make images)

$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.518s][info ][gc,phases] GC(0) Phase 1: Mark live objects 68.763ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.499s][info ][gc,phases] GC(0) Phase 1: Mark live objects 69.115ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.509s][info ][gc,phases] GC(0) Phase 1: Mark live objects 75.952ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.519s][info ][gc,phases] GC(0) Phase 1: Mark live objects 68.478ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.529s][info ][gc,phases] GC(0) Phase 1: Mark live objects 69.646ms

$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.499s][info ][gc,phases] GC(0) Phase 1: Mark live objects 68.603ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.519s][info ][gc,phases] GC(0) Phase 1: Mark live objects 72.012ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.515s][info ][gc,phases] GC(0) Phase 1: Mark live objects 69.525ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.512s][info ][gc,phases] GC(0) Phase 1: Mark live objects 69.656ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.512s][info ][gc,phases] GC(0) Phase 1: Mark live objects 69.365ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.517s][info ][gc,phases] GC(0) Phase 1: Mark live objects 69.441ms

$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.501s][info ][gc,phases] GC(0) Phase 1: Mark live objects 67.338ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.511s][info ][gc,phases] GC(0) Phase 1: Mark live objects 75.821ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.508s][info ][gc,phases] GC(0) Phase 1: Mark live objects 68.903ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.499s][info ][gc,phases] GC(0) Phase 1: Mark live objects 68.870ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.495s][info ][gc,phases] GC(0) Phase 1: Mark live objects 67.374ms
$ java -Xlog:gc+phases=trace SystemGCLarge | grep "Phase 1: Mark live objects"
[0.501s][info ][gc,phases] GC(0) Phase 1: Mark live objects 69.018ms

Loading

@kstefanj
Copy link
Contributor

@kstefanj kstefanj commented Mar 18, 2021

Thanks for verifying.

Loading

Copy link
Contributor

@tschatzl tschatzl left a comment

Lgtm assuming that Windows build failure is just something specific to Github. Thanks.

To answer my own question: it builds internally on Windows. So it's good to go.

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Mar 18, 2021

@Hamlin-Li 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:

8263495: Gather liveness info in the mark phase of G1 full gc

Co-authored-by: Shoubing Ma <mashoubing1@huawei.com>
Reviewed-by: tschatzl, sjohanss

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

  • a85dc55: 8263311: Watch registry changes for remote printers update instead of polling
  • 3f31a6b: 8263775: C2: igv_print() crash unexpectedly when called from debugger
  • 63eae8f: 8260605: Various java.lang.invoke cleanups
  • 9cd21b6: 8263590: Rawtypes warnings should be produced for pattern matching in instanceof
  • ff52f29: 8260716: Assert in MacroAssembler::clear_mem with -XX:-IdealizeClearArrayNode
  • 72b82fd: 8263725: JFR oldobject tests are not run when GCs are specified explicitly
  • 444a80b: 8263455: NMT: assert on registering a region which completely engulfs an existing region
  • 2b93ae0: 8261480: MetaspaceShared::preload_and_dump should check exceptions
  • 81ba578: 8263676: AArch64: one potential bug in C1 LIRGenerator::generate_address()
  • 9225a23: 8263108: Class initialization deadlock in java.lang.constant
  • ... and 781 more: https://git.openjdk.java.net/jdk/compare/35c9da70316da21a6be2fd92a5e5b5f193bdd9d6...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.

Loading

@openjdk openjdk bot added the ready label Mar 18, 2021
Copy link
Contributor

@kstefanj kstefanj left a comment

I'm good with the current changes as well.

Loading

@Hamlin-Li
Copy link
Author

@Hamlin-Li Hamlin-Li commented Mar 18, 2021

/integrate

Loading

for (uint j = 0; j < heap->max_regions(); j++) {
_live_stats[j].clear();
}
Copy link
Member

@albertnetymk albertnetymk Mar 18, 2021

Choose a reason for hiding this comment

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

Nit: i could be used instead of j, right?

Loading

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

@openjdk openjdk bot commented Mar 18, 2021

@Hamlin-Li Since your change was applied there have been 791 commits pushed to the master branch:

  • a85dc55: 8263311: Watch registry changes for remote printers update instead of polling
  • 3f31a6b: 8263775: C2: igv_print() crash unexpectedly when called from debugger
  • 63eae8f: 8260605: Various java.lang.invoke cleanups
  • 9cd21b6: 8263590: Rawtypes warnings should be produced for pattern matching in instanceof
  • ff52f29: 8260716: Assert in MacroAssembler::clear_mem with -XX:-IdealizeClearArrayNode
  • 72b82fd: 8263725: JFR oldobject tests are not run when GCs are specified explicitly
  • 444a80b: 8263455: NMT: assert on registering a region which completely engulfs an existing region
  • 2b93ae0: 8261480: MetaspaceShared::preload_and_dump should check exceptions
  • 81ba578: 8263676: AArch64: one potential bug in C1 LIRGenerator::generate_address()
  • 9225a23: 8263108: Class initialization deadlock in java.lang.constant
  • ... and 781 more: https://git.openjdk.java.net/jdk/compare/35c9da70316da21a6be2fd92a5e5b5f193bdd9d6...master

Your commit was automatically rebased without conflicts.

Pushed as commit 8c8d1b3.

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

Loading

@Hamlin-Li Hamlin-Li deleted the gather-liveness-g1 branch Mar 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants