8027545: Improve object array chunking test in G1's copy_to_survivor_space #90

kimbarrett · 2020-09-09T07:24:27Z

/issue add JDK-8158045
/issue add JDK-8027761
/issue add JDK-8027545

This is rework of initial change from before the transition to git.
The initial RFR email is attached below.

The primary change is to limit the number of partial array tasks in
the queues for any given array. The original change just split up an
array into N tasks that were all enqueued at once. But for a large
array this could be a lot of tasks, leading to significant and
unnecessary queue expansion. Instead we now limit the number of tasks
for a given array based on the number of workers, and only gradually
add tasks up to that limit. This gives other threads an opportunity
to steal such tasks, while still keeping queue growth under control.

Most of the calculation for this is handled by a new helper class, so
this can later be shared with ParallelGC.

The dispatch on array klass type for has also been changed. It now
affirmatively breaks Project Valhalla, rather than quietly doing
something that probably isn't what is actually wanted. I'll discuss
with them so there is a plan for dealing with it when they take this
update.

Ran tier1-6 in mach5 and some local stress tests.

Performance testing was unchanged from previous, except I wasn't able
to reproduce the small specjbb2015 critical-jops improvement
previously seen on one platform. My suspicion is that improvement was
a statistical abberation.

--- Initial RFR email ---

RFR: 8158045: Improve large object handling during evacuation
RFR: 8027761: Investigate fast-path for scanning only objects with references during gc
RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space

Please review this change to type dispatching and handling in G1's
evacuation copying, in order to improve the hot paths and improve array
handling. This change addresses several closely co-located enhancement
requests; it seemed difficult to split them up in a sensible way.

do_copy_to_survivor_space now gets the klass of the object being copied
once, up front, for use in multiple places. This avoids fetching (including
re-decoding when compressed) the klass multiple times. This addresses part
of JDK-8027545.

Moved check for and handling of string deduplication later, only applying it
after the special array cases have been dealt with, since strings are not
arrays. (They are header objects pointing to an array of character values.)

Special case typeArray, doing nothing other than the copy, since they
contain no oops that need to be processed. This addresses JDK-8027761.

Changed handling of objArray, pushing all of the partial array tasks up
front, rather than processing the current chunk after pushing a single task
for the remaining work. This addresses JDK-8158045.

As part of these, cached some more frequently accessed values in
G1ParScanThreadState member variables. This addresses part of part of
JDK-8027545.

While both the old and new code will work for Project Valhalla, the handling
of arrays should be updated for that project, which introduces new array
types.

Deleted a lingering reference to G1ParScanPartialArrayClosure that was
deleted long ago (JDK-8035330, JDK 9).

CR:
https://bugs.openjdk.java.net/browse/JDK-8158045
https://bugs.openjdk.java.net/browse/JDK-8027761
https://bugs.openjdk.java.net/browse/JDK-8027545

Webrev:
https://cr.openjdk.java.net/~kbarrett/8158045/open.00/

Testing:
tier1-3

performance testing - seems to be at worst performance neutral, with a
statistically significant 3% improvement in specjbb2015 critical-jops seen
on one platform.

Progress

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

Issues

JDK-8027545: Improve object array chunking test in G1's copy_to_survivor_space
JDK-8158045: Improve large object handling during evacuation
JDK-8027761: Investigate fast-path for scanning only objects with references during gc

Reviewers

Stefan Johansson (@kstefanj - Reviewer) ⚠️ Review applies to 1981c39
Albert Mingkun Yang (@albertnetymk - Author) ⚠️ Review applies to 1981c39
Thomas Schatzl (@tschatzl - Reviewer) ⚠️ Review applies to 1981c39

Download

$ git fetch https://git.openjdk.java.net/jdk pull/90/head:pull/90
$ git checkout pull/90

…traction

bridgekeeper · 2020-09-09T07:25:52Z

👋 Welcome back kbarrett! 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 · 2020-09-09T07:26:28Z

@kimbarrett The primary solved issue for a PR is set through the PR title. Since the current title does not contain an issue reference, it will now be updated.

openjdk · 2020-09-09T07:26:52Z

@kimbarrett The primary solved issue for a PR is set through the PR title. Since the current title does not contain an issue reference, it will now be updated.

openjdk · 2020-09-09T07:27:15Z

@kimbarrett The primary solved issue for a PR is set through the PR title. Since the current title does not contain an issue reference, it will now be updated.

openjdk · 2020-09-09T07:28:08Z

@kimbarrett The following label will be automatically applied to this pull request: hotspot.

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 (add|remove) "label" command.

mlbridge · 2020-09-09T07:31:59Z

Webrevs

kimbarrett · 2020-09-09T07:38:22Z

/label add hotspot-gc

openjdk · 2020-09-09T07:38:49Z

@kimbarrett
The hotspot-gc label was successfully added.

kimbarrett · 2020-09-09T08:50:10Z

The title for this review was supposed to be based on JDK-8158045 "Improve large object handling during evacuation", but because of SKARA-634 the last of the three associated issue commands was used, rather than the first.

albertnetymk · 2020-09-09T12:34:45Z

src/hotspot/share/gc/g1/g1ParScanThreadState.cpp

+  PartialArrayTaskStepper::Step step
+    = _partial_array_stepper.start(objArrayOop(from_obj),
+                                   to_array,
+                                   _partial_objarray_chunk_size);
+
+  // Push any needed partial scan tasks.  Pushed before processing the
+  // intitial chunk to allow other workers to steal while we're processing.
+  for (uint i = 0; i < step._ncreate; ++i) {
+    push_on_queue(ScannerTask(PartialArrayScanTask(from_obj)));
+  }


I think the intention would be clearer, if start returns a pair <int intial_chunk_size, bool has_left_over> instead of reusing Step struct.

I reused Step intentionally, to not commit at this layer to only creating one partial task. The stepper can change its calculations and this layer won't care.

albertnetymk · 2020-09-09T12:36:11Z

src/hotspot/share/gc/g1/g1ParScanThreadState.cpp

+      return obj;
+    }
+
+    if (G1StringDedup::is_enabled() && (klass == SystemDictionary::String_klass())) {


It's unclear to me why the additional checking with String_klass().

Faster fast-path, avoiding some of the other calculations before going into G1StringDedup::enqueue_from_evacuation and only there discovering we're not dealing with a String at all. But this doesn't belong in this changeset. I'll remove it.

albertnetymk · 2020-09-09T12:39:37Z

src/hotspot/share/oops/arrayOop.hpp

@@ -104,12 +104,19 @@ class arrayOopDesc : public oopDesc {

  // Accessors for instance variable which is not a C++ declared nonstatic
  // field.
-  int length() const {
-    return *(int*)(((intptr_t)this) + length_offset_in_bytes());
+  int length() const { return *length_addr(); }


Personally, I find the original code easier to read, since the identical content, *(int*)(((char*)mem) + length_offset_in_bytes()) exists in both length() and set_length(HeapWord* mem, int length).

I should have included the 2-arg set_length in the changes to make everything consistent. I'll revise in the next update.

kstefanj

Overall a very nice improvement. Some comments and ideas below.

kstefanj · 2020-09-09T12:07:38Z

src/hotspot/share/gc/g1/g1ParScanThreadState.hpp

@@ -79,6 +80,9 @@ class G1ParScanThreadState : public CHeapObj<mtGC> {
  // Indicates whether in the last generation (old) there is no more space
  // available for allocation.
  bool _old_gen_is_full;
+  // Size (in elements) of a partial objArray task chunk.
+  int _partial_objarray_chunk_size;


I would prefer to skip the "obj"-part here to have more consistent naming or, as mentioned above, include it in the stepper instead.

Some of the naming and factoring I've done is forward looking.

I think we should consider splitting the copying part as well as the scanning, and chunking the copy of typeArrays. For example, JDK-8031565 suggests copying large typeArrays as part of termination waiting; I think splitting them into partial array tasks to use the normal parallelism in the framework is better than some new side channel. The chunk size for that should probably be substantially larger (and depend on the element size) than for objArray.

Also, Project Valhalla is going to add new kinds of arrays that are neither objArray nor typeArray. We'll want to split them too. The same splitting calculations can apply, even though the chunk size may be different (and probably depends on the element klass).

Ok, keeping the "obj"-part sounds reasonable.

kstefanj · 2020-09-09T12:14:31Z

src/hotspot/share/gc/g1/g1ParScanThreadState.hpp

@@ -157,6 +162,7 @@ class G1ParScanThreadState : public CHeapObj<mtGC> {

 private:
  inline void do_partial_array(PartialArrayScanTask task);
+  inline void start_partial_objArray(G1HeapRegionAttr dest_dir, oop from, oop to);


Same here, drop "obj" for consistent naming and avoiding the camel-case.

See response above about the name of _partial_objarray_chunk_size. But I should probably be consistent about objarray vs objArray. Since objArray is what it is over in runtime oop-land I'm going to go with that.

Again, we have different taste. We very seldom go with camel-case in members and especially in the middle it looks strange. Looking through the GC-code I find mostly objarray or obj_array

You are right; in gc code, it seems "objarray" is used almost exclusively. The one exception I found seems to be around the G1CMObjArrayProcessor, where some camel-case has snuck in, such as G1ConcurrentMark::_objArray_processor. So I'll use "objarray".

kstefanj · 2020-09-09T12:19:34Z

src/hotspot/share/gc/shared/partialArrayTaskStepper.cpp

+static uint compute_task_limit(uint n_workers) {
+  // Don't need more than n_workers tasks at a time.  But allowing up to
+  // that maximizes available parallelism.
+  return n_workers;
+}


In preparation for a more advanced logic for the limit, or why not just use the input at the call-site?

Being noncommittal about whether something more "clever" could or should be done.

kstefanj · 2020-09-09T12:28:11Z

src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp

+
+  // The from-space object contains the real length.
+  int length = from->length();
+  assert(start < length, "invariant: start %d, length %d", start, length);


Just so I'm not missing anything. There will never be more tasks than chunks left, so there is no risk that we have a race for the last chunk and thus hit this assertion?

That's correct. Unless there's a bug in the analysis or implementation I haven't found. That's why it's an invariant.

kstefanj · 2020-09-09T12:49:56Z

src/hotspot/share/gc/g1/g1ParScanThreadState.cpp

+    _partial_objarray_chunk_size(ParGCArrayScanChunk),
+    _partial_array_stepper(n_workers),


What do you think about saving the chunk size in the stepper instead? Then we don't need to pass it in to start() and next(). To avoid needing it for the call to oop_iterate_range() we could instead have the Step include both the start and end index.

See above discussion about naming and factoring. The same stepper can support multiple array types if the chunk size is external to the stepper.

It can, but I think I would prefer multiple "steppers" for that case. This is of course just a matter of taste and I'm fine with leaving the chunk size external.

kstefanj · 2020-09-09T12:55:12Z

src/hotspot/share/gc/shared/partialArrayTaskStepper.hpp

+  struct Step {
+    int _index;                 // Array index for the step.
+    uint _ncreate;              // Number of new tasks to create.
+  };


I wouldn't mind having getters for those, but it's not a hard request :)

Step is intended to be a trivial data carrier. A (HotSpot) Pair or std::pair (if we used stdlib) would do, except I like named data items.

I prefer them named as well 👍

kstefanj · 2020-09-09T18:34:45Z

src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp

+  assert(_task_limit > 0, "precondition");
+  assert(_task_fannout > 0, "precondition");
+  uint max_pending = (_task_fannout - 1) * task_num + 1;
+
+  // The actual pending may be less than that.  Bound by remaining_tasks to
+  // not overrun.  Also bound by _task_limit to avoid spawning an excessive
+  // number of tasks for a large array.  The +1 is to replace the current
+  // task with a new task when _task_limit limited.  The pending value may
+  // not be what's actually in the queues, because of concurrent task
+  // processing.  That's okay; we just need to determine the correct number
+  // of tasks to add for this task.
+  uint pending = MIN3(max_pending, remaining_tasks, _task_limit);
+  uint ncreate = MIN2(_task_fannout, MIN2(remaining_tasks, _task_limit + 1) - pending);
+  Step result = { start, ncreate };
+  return result;


Similar to my comment above, what do you think about trying to write some test for this to verify we never get to many "tasks".

The asserts in the stepper's next() after the increment of to's length verify that we haven't overrun. I haven't thought of a way to verify the algorithm doesn't generate too few tasks though. Well, other than getting crashes because some array elements didn't get processed. But maybe you mean unit tests? I will try to write some; I should have done so already.

Should have been a bit more clear. I'm talking about unit tests, so if you plan writing some that's great.

mlbridge · 2020-09-10T14:25:24Z

Mailing list message from Kim Barrett on hotspot-dev:

On Sep 10, 2020, at 10:08 AM, Kim Barrett <kbarrett at openjdk.java.net> wrote:

On Wed, 9 Sep 2020 12:49:56 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 68:

66: _old_gen_is_full(false),
67: _partial_objarray_chunk_size(ParGCArrayScanChunk),
68: _partial_array_stepper(n_workers),

What do you think about saving the chunk size in the stepper instead? Then we don't need to pass it in to `start()` and
`next()`. To avoid needing it for the call to `oop_iterate_range()` we could instead have the `Step` include both the
start and end index.

See above discussion about naming and factoring. The same stepper can support multiple array types if the chunk size
is external to the stepper.

Well, that discussion is only ?above" in the github UI tool.

Now that I see what happens when I reply there, maybe I won?t do that so much.
That?s seriously chatty and massively quoting redundant.

kstefanj

Nice test and thanks for going with "objarray".

Looks good and I'll approve this now, but please fix the indent issue in the test before integrating.

kstefanj · 2020-09-11T10:18:35Z

test/hotspot/gtest/gc/shared/test_partialArrayTaskStepper.cpp

+                     int length,
+                     int* to_length_addr,
+                     uint chunk_size) {


Indent looks to be one-off here.

openjdk · 2020-09-11T10:45:31Z

@kimbarrett This change now passes all automated pre-integration checks. In addition to the automated checks, the change must also fulfill all project specific requirements

After integration, the commit message will be:

8027545: Improve object array chunking test in G1's copy_to_survivor_space
8158045: Improve large object handling during evacuation
8027761: Investigate fast-path for scanning only objects with references during gc

Generate multiple partial array tasks for large objArrays.

Reviewed-by: sjohanss, ayang, tschatzl

If you would like to add a summary, use the /summary command.
To credit additional contributors, use the /contributor command.
To add additional solved issues, use the /issue command.

Since the source branch of this PR was last updated there have been 49 commits pushed to the master branch:

7eb4d4a: 8247909: Improve PrimitiveConversions::cast using C++14
fa30241: 8249676: [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
9ea43a9: 8253148: Fix terminology in align_down comment
3f455f0: 8253089: Windows (MSVC 2017) build fails after JDK-8243208
af8c678: 8247910: Improve alignment and power-of-2 utilities using C++14
70cc7fc: 8253098: Archived full module graph should be disabled if CDS heap cannot be mapped
ac9d1b0: 8223187: Remove setLocale() call in jpackage native launcher
9c24a56: 8253029: [PPC64] Remove obsolete Power6 code
e6a493a: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler
68da63d: 8240658: Code completion not working for lambdas in method invocations that require type inference
... and 39 more: https://git.openjdk.java.net/jdk/compare/c655b703a9f66dad54c8edb0bac332ac2decc820...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge master into your branch, and then specify the current head hash when integrating, like this: /integrate 7eb4d4aa018e37052cbf37cd854380006c309645.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

mlbridge · 2020-09-11T12:51:53Z

Mailing list message from Thomas Schatzl on hotspot-dev:

Hi,

On 11.09.20 11:01, Kim Barrett wrote:
[...]

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

Respond to reviews by ayang and sjohanss.

- partialArrayTaskStepper.hpp:

s/_task_fannout/_task_fanout (or maybe _task_fan_out)

- since _task_fannout and _task_limit are only assigned in the
constructor of PartialArrayTaskStepper, maybe make them const?

- also the asserts in PartialArrayTaskStepper::next_impl could be
moved to the constructor initialization list but otoh the fannout > 0
assert does make the calculation below immediately obviously safe.

Looks good otherwise.

Thanks,
Thomas

mlbridge · 2020-09-12T00:31:48Z

Mailing list message from Kim Barrett on hotspot-dev:

On Sep 11, 2020, at 6:47 AM, Stefan Johansson <sjohanss at openjdk.java.net> wrote:

On Fri, 11 Sep 2020 09:01:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

Respond to reviews by ayang and sjohanss.

Nice test and thanks for going with "objarray".

Looks good and I'll approve this now, but please fix the indent issue in the test before integrating.

Thanks, will do.

test/hotspot/gtest/gc/shared/test_partialArrayTaskStepper.cpp line 55:

53: int length,
54: int* to_length_addr,
55: uint chunk_size) {

Indent looks to be one-off here.

Yeah, changed return type from void to int at some point and missed adjusting the indentation.

mlbridge · 2020-09-12T01:03:04Z

Mailing list message from Kim Barrett on hotspot-dev:

On Sep 11, 2020, at 8:50 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:

Hi,

On 11.09.20 11:01, Kim Barrett wrote:
[...]

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
Respond to reviews by ayang and sjohanss.

- partialArrayTaskStepper.hpp:

s/_task_fannout/_task_fanout (or maybe _task_fan_out)

I thought it looked a little odd at first, but never got around to spell
checking it, and after a while it looked fine by familiarity. Will fix
("fanout").

- since _task_fannout and _task_limit are only assigned in the constructor of PartialArrayTaskStepper, maybe make them const?

I'd rather not. I've been down that road and didn't like the results. Just
as an example, doing that sort of thing renders a class copyable but not
assignable, swappable, or (in some cases) moveable from. That's an odd
combination. I already (though recently) made start() and next() const.

- also the asserts in PartialArrayTaskStepper::next_impl could be moved to the constructor initialization list but otoh the fannout > 0 assert does make the calculation below immediately obviously safe.

As you say, the current location shows the requirements for the nearby
calculations.

Looks good otherwise.

Thanks.

Thanks,
Thomas

kimbarrett · 2020-09-12T08:24:25Z

/issue add 8158045 8027761 8027545

openjdk · 2020-09-12T08:25:35Z

@kimbarrett
Adding additional issue to issue list: 8158045: Improve large object handling during evacuation.

Adding additional issue to issue list: 8027761: Investigate fast-path for scanning only objects with references during gc.
This issue is referenced in the PR title - it will now be updated.

mlbridge · 2020-09-15T09:36:40Z

Mailing list message from Thomas Schatzl on hotspot-dev:

Hi,

On 12.09.20 03:02, Kim Barrett wrote:

On Sep 11, 2020, at 8:50 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:

Hi,

On 11.09.20 11:01, Kim Barrett wrote:
[...]

- partialArrayTaskStepper.hpp:

s/_task_fannout/_task_fanout (or maybe _task_fan_out)

I thought it looked a little odd at first, but never got around to spell
checking it, and after a while it looked fine by familiarity. Will fix
("fanout").

- since _task_fannout and _task_limit are only assigned in the constructor of PartialArrayTaskStepper, maybe make them const?

I'd rather not. I've been down that road and didn't like the results. Just
as an example, doing that sort of thing renders a class copyable but not
assignable, swappable, or (in some cases) moveable from. That's an odd
combination. I already (though recently) made start() and next() const.

- also the asserts in PartialArrayTaskStepper::next_impl could be moved to the constructor initialization list but otoh the fannout > 0 assert does make the calculation below immediately obviously safe.

As you say, the current location shows the requirements for the nearby
calculations.

Looks good otherwise.

Okay. Going to mark this as reviewed assuming the rename will be done.

Thanks,
Thomas

kimbarrett · 2020-09-15T11:55:12Z

/summary Generate multiple partial array tasks for large objArrays.

openjdk · 2020-09-15T11:55:52Z

@kimbarrett Setting summary to Generate multiple partial array tasks for large objArrays.

kimbarrett · 2020-09-15T12:17:02Z

/integrate

openjdk · 2020-09-15T12:18:38Z

@kimbarrett Since your change was applied there have been 49 commits pushed to the master branch:

7eb4d4a: 8247909: Improve PrimitiveConversions::cast using C++14
fa30241: 8249676: [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
9ea43a9: 8253148: Fix terminology in align_down comment
3f455f0: 8253089: Windows (MSVC 2017) build fails after JDK-8243208
af8c678: 8247910: Improve alignment and power-of-2 utilities using C++14
70cc7fc: 8253098: Archived full module graph should be disabled if CDS heap cannot be mapped
ac9d1b0: 8223187: Remove setLocale() call in jpackage native launcher
9c24a56: 8253029: [PPC64] Remove obsolete Power6 code
e6a493a: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler
68da63d: 8240658: Code completion not working for lambdas in method invocations that require type inference
... and 39 more: https://git.openjdk.java.net/jdk/compare/c655b703a9f66dad54c8edb0bac332ac2decc820...master

Your commit was automatically rebased without conflicts.

Pushed as commit dafcf10.

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

8302038: compiler implementation for statements before super(), first iteration

Co-authored-by: Xin Liu <xxinliu@amazon.com>

kimbarrett added 2 commits September 9, 2020 02:00

Initial RFR for partial_arrays

164107c

limit partial array tasks, add length_addr() rather than breaking abs…

9397514

…traction

kimbarrett marked this pull request as ready for review September 9, 2020 07:25

openjdk bot changed the title ~~Partial arrays~~ 8158045: Improve large object handling during evacuation Sep 9, 2020

openjdk bot changed the title ~~8158045: Improve large object handling during evacuation~~ 8027761: Investigate fast-path for scanning only objects with references during gc Sep 9, 2020

openjdk bot changed the title ~~8027761: Investigate fast-path for scanning only objects with references during gc~~ 8027545: Improve object array chunking test in G1's copy_to_survivor_space Sep 9, 2020

openjdk bot added the rfr Pull request is ready for review label Sep 9, 2020

openjdk bot added the hotspot hotspot-dev@openjdk.org label Sep 9, 2020

openjdk bot added the hotspot-gc hotspot-gc-dev@openjdk.org label Sep 9, 2020

albertnetymk reviewed Sep 9, 2020

View reviewed changes

kstefanj suggested changes Sep 9, 2020

View reviewed changes

Respond to reviews by ayang and sjohanss.

1981c39

kstefanj approved these changes Sep 11, 2020

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Sep 11, 2020

Respond to reviews by sjohanss and tschatzl

1c8c0a8

albertnetymk approved these changes Sep 15, 2020

View reviewed changes

tschatzl approved these changes Sep 15, 2020

View reviewed changes

openjdk bot closed this Sep 15, 2020

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 15, 2020

kimbarrett deleted the partial_arrays branch September 15, 2020 12:27

kimbarrett mentioned this pull request Sep 19, 2020

8253237: [REDO] Improve large object handling during evacuation #266

Closed

3 tasks

mrserb mentioned this pull request Oct 25, 2020

8028281: [TEST_BUG] [macosx] javax/swing/JTabbedPane/7024235/Test7024235.java fails #852

Closed

3 tasks

archiecobbs pushed a commit to archiecobbs/jdk that referenced this pull request Apr 20, 2023

Merge pull request openjdk#90 from vicente-romero-oracle/initial.push

e935c97

8302038: compiler implementation for statements before super(), first iteration

robehn pushed a commit to robehn/jdk that referenced this pull request Aug 15, 2023

SW-3147: Do fastdebug builds on ci (openjdk#90)

1717fc9

caojoshua pushed a commit to caojoshua/jdk that referenced this pull request Jan 19, 2024

[redo] Dump CFG in RPO order before Parsing. (openjdk#90)

52a9e94

Co-authored-by: Xin Liu <xxinliu@amazon.com>

calvinccheung mentioned this pull request Mar 5, 2024

8327138: Clean up status management in cdsConfig.hpp and CDS.java #18095

Closed

3 tasks

		_partial_objarray_chunk_size(ParGCArrayScanChunk),
		_partial_array_stepper(n_workers),

8027545: Improve object array chunking test in G1's copy_to_survivor_space #90

8027545: Improve object array chunking test in G1's copy_to_survivor_space #90

Conversation

kimbarrett commented Sep 9, 2020 • edited by openjdk bot Loading

Progress

Issues

Reviewers

Download

bridgekeeper bot commented Sep 9, 2020

openjdk bot commented Sep 9, 2020

openjdk bot commented Sep 9, 2020

openjdk bot commented Sep 9, 2020

openjdk bot commented Sep 9, 2020

mlbridge bot commented Sep 9, 2020 • edited Loading

Webrevs

kimbarrett commented Sep 9, 2020

openjdk bot commented Sep 9, 2020

kimbarrett commented Sep 9, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kstefanj left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mlbridge bot commented Sep 10, 2020

kstefanj left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

openjdk bot commented Sep 11, 2020 • edited Loading

mlbridge bot commented Sep 11, 2020

mlbridge bot commented Sep 12, 2020

mlbridge bot commented Sep 12, 2020

kimbarrett commented Sep 12, 2020

openjdk bot commented Sep 12, 2020

mlbridge bot commented Sep 15, 2020

kimbarrett commented Sep 15, 2020

openjdk bot commented Sep 15, 2020

kimbarrett commented Sep 15, 2020

openjdk bot commented Sep 15, 2020

kimbarrett commented Sep 9, 2020 •

edited by openjdk bot

Loading

mlbridge bot commented Sep 9, 2020 •

edited

Loading

openjdk bot commented Sep 11, 2020 •

edited

Loading