8261447: MethodInvocationCounters frequently run into overflow #2511

RealLucy · 2021-02-10T16:28:29Z

Dear community,
may I please request reviews for this fix, improving the usefulness of method invocation counters.

aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
before/after sample output is attached to the bug description.

Thank you!
Lutz

Progress

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

Issue

JDK-8261447: MethodInvocationCounters frequently run into overflow

Reviewers

Tobias Hartmann (@TobiHartmann - Reviewer) ⚠️ Review applies to e8af119
Martin Doerr (@TheRealMDoerr - Reviewer) ⚠️ Review applies to e8af119
Vladimir Kozlov (@vnkozlov - Reviewer)
Igor Veresov (@veresov - Reviewer)

Download

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

bridgekeeper · 2021-02-10T16:28:56Z

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

RealLucy · 2021-02-10T16:28:59Z

/cc hotspot-dev

openjdk · 2021-02-10T16:29:29Z

@RealLucy
The hotspot label was successfully added.

mlbridge · 2021-02-10T16:32:45Z

Webrevs

09: Full - Incremental (0faea5a)
08: Full - Incremental (5c27640)
07: Full - Incremental (e8af119)
06: Full - Incremental (0f220ee)
05: Full - Incremental (faab64b)
04: Full - Incremental (0a99ee4)
03: Full (273d55c2fdae4c3c2e32c8a00cac95c5183d6545)
02: Full - Incremental (67fb3f7d2878afd80972ad8fc8e8e68b467f572a)
01: Full - Incremental (bfd60a3c06b6e338435a4ae12c43f14e5062b00a)
00: Full (868ff38bee0bad3e20f6d236a95d6fa105b3e7dd)

TobiHartmann · 2021-02-11T08:28:47Z

src/hotspot/share/oops/method.hpp

@@ -708,6 +725,7 @@ class Method : public Metadata {
  }
 #ifndef PRODUCT
  static ByteSize compiled_invocation_counter_offset() { return byte_offset_of(Method, _compiled_invocation_count); }
+  static ByteSize compiled_invocation_counter_offset64() { return byte_offset_of(Method, _compiled_invocation_count64); }


compiled_invocation_counter_offset() looks unused.

Correct. Removed.

TobiHartmann · 2021-02-11T08:33:18Z

src/hotspot/share/oops/method.hpp

 #else
  // for PrintMethodData in a product build
-  int  compiled_invocation_count() const        { return 0;  }
+  int      compiled_invocation_count() const    { return 0; }


compiled_invocation_count() looks unused.

compiled_invocation_count() was used in compare_methods() and collect_invoked_methods(). I have converted those call sites to compiled_invocation_count64().

TobiHartmann · 2021-02-11T08:33:40Z

src/hotspot/share/oops/method.hpp

+#if defined(VM_LITTLE_ENDIAN)
+    struct {
+      int     _compiled_invocation_count;  // Number of nmethod invocations so far (for perf. debugging)
+                                           // Must preserve this as int. Is used outside the jdk by SA.


Why not update the SA code to access 64 bit?

Two reasons: scope limitation and lack of expertise in SA code. Don't we need the 32bit decl anyway because it is contained in vmstructs.cpp?

RealLucy · 2021-02-11T13:39:15Z

Thank you Tobias for having a look. I'll post an update asap.

vnkozlov · 2021-02-11T18:22:38Z

@veresov please review these changes

veresov · 2021-02-11T20:45:30Z

I don't really like these .*64 suffixes. Can we just make the counter 64 bit, update the SA as Tobias suggested and keep the existing method names? Or is there a reason for doing this that eludes me?

RealLucy · 2021-02-12T08:29:37Z

I introduced the *64 suffixes to not break anything that still uses the old calls. As old uses disappear step by step, I'm more than happy to remove the suffixes. I will have a look into SA and try to make it 64bit counter ready. There may be no new version before the weekend is over.

RealLucy · 2021-02-12T11:58:47Z

/cc serviceability-dev

This is a request for help. Could someone with SA knowledge please check if my assumption is correct?

In hotspot code, the field Method::_compiled_invocation_count is annotated with a comment that it is used by SA. The field is also exposed via vmStructs.cpp to enable such use. I have scanned SA code in OpenJDK11 and OpenJDK head but found no evidence that this particular field is accessed. Is this finding/assumption correct?

If so, I could just stop exposing the field, making my life easier. Thanks!

openjdk · 2021-02-12T11:59:03Z

@RealLucy
The serviceability label was successfully added.

openjdk · 2021-02-15T18:03:18Z

⚠️ @RealLucy This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

RealLucy · 2021-02-15T18:21:53Z

Looks like I have completely messed up my pull request. Please disregard for now. I'm trying to find a way how to clean up. Maybe I'll just start over.

RealLucy · 2021-02-17T18:25:01Z

OK, my pull request is back in a reviewable state. Here is what changed:

Honouring review comments from @TobiHartmann and @veresov
Trusting my own code research, I removed _compiled_invocation_count from vmStructs.cpp. Builds are ok and all tests we run in-house (including the jtreg suite) did not show any issue. The updated pull request has _compiled_invocation_count widened to 64-bit and all those *64 suffixes are removed.
Dealing with counter updates in {v|i}table stubs
While waiting for a response from SA experts, I took the time and had a closer look at the last remaining 32-bit counter (_nof_megamorphic_calls). It turned out the required changes to code generation were trivial. So I took the opportunity and made it a 64-bit counter. Call stats look even nicer now!

In summary: All global invocation counters are 64-bit now. From those counters that register method-individual calls, only _compiled_invocation_count and _nof_megamorphic_calls were widened to 64-bit. The three remaining method-individual counters (invocation_count, interpreter_invocation_count. and backedge_count) remain untouched.

I appreciate your feedback!

Here is how stats look like now:

Invocations summary for 28214 methods:
         41055191904 (100%)  total
          4818528940 (11.7%) |- interpreted
         36236662964 (88.3%) |- compiled
          9065026571 (22.1%) |- special methods (interpreted and compiled)
           607128840 ( 1.5%)    |- synchronized
          2107652419 ( 5.1%)    |- final
          6347934023 (15.5%)    |- static
             1122857 ( 0.0%)    |- native
             1188432 ( 0.0%)    |- accessor

Calls from compiled code:
         27011733837 (100%)  total non-inlined
         14500960686 (53.7%) |- virtual calls
        124325246564 ( 857%) |  |- inlined
                   0 (   0%) |  |- optimized
          8890453008 (  61%) |  |- monomorphic
          5610507678 (  39%) |  |- megamorphic
          4529160753 (16.8%) |- interface calls
          8905052200 ( 197%) |  |- inlined
                   0 (   0%) |  |- optimized
          4529160753 ( 100%) |  |- monomorphic
                   0 (   0%) |  |- megamorphic
          7981612398 (29.5%) |- static/special calls
         73886243527 ( 926%) |  |- inlined

dholmes-ora · 2021-02-18T05:12:08Z

src/hotspot/share/oops/method.cpp

-  tty->print_cr ("  interpreter_invocation_count: %8d ", interpreter_invocation_count());
-  tty->print_cr ("  invocation_counter:           %8d ", invocation_count());
-  tty->print_cr ("  backedge_counter:             %8d ", backedge_count());
+  // Internal counting is based on signed int counters. They tend to


Is there a good reason to not simply make them unsigned int?

Well, depends on what you accept as a good reason. :-)

I decided to keep the counters as they are to limit the scope of the change. A grep for backedge_counter returns 94 lines, for example. Deep down, these counters are InvocationCounters, declared as uint. On their way up to the surface, they are treated signed or unsigned. Pretty inconsistent, yes. But a huge task to get it all straight, including checking/fixing assembly code.

Is that reason enough?

mlbridge · 2021-02-18T12:57:39Z

Mailing list message from David Holmes on hotspot-dev:

On 18/02/2021 9:25 pm, Lutz Schmidt wrote:

On Thu, 18 Feb 2021 05:12:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:

update copyright year

src/hotspot/share/oops/method.cpp line 511:

509: tty->cr();
510:
511: // Internal counting is based on signed int counters. They tend to

Is there a good reason to not simply make them unsigned int?

Well, depends on what you accept as a good reason. :-)

I decided to keep the counters as they are to limit the scope of the change. A grep for backedge_counter returns 94 lines, for example. Deep down, these counters are InvocationCounters, declared as uint. On their way up to the surface, they are treated signed or unsigned. Pretty inconsistent, yes. But a huge task to get it all straight, including checking/fixing assembly code.

Is that reason enough?

I guess so :) It sounds terribly messy and confused.

Thanks,
David

TheRealMDoerr

This version looks ok. I understand that you don't want to clean up the whole singed / unsigned mess. That's fine with me. I'd only like to see one confusing comment removed or replaced.
You may also want to check your 64 bit overflow time in the description: I guess 185 days matches a 1 THz counter update frequency. With 1 GHz it should be above 500 years.

TheRealMDoerr · 2021-02-24T22:28:15Z

src/hotspot/share/runtime/java.cpp

-  return ((*b)->invocation_count() + (*b)->compiled_invocation_count())
-       - ((*a)->invocation_count() + (*a)->compiled_invocation_count());
+  // invocation_count() may have overflowed already. Interpret it's result as
+  // unsigned int to shift the limit of meaningless results by a factor of 2.


Code is fine, but this comment doesn't make sense to me. The result is the same with your version. But it has the advantage that it avoids signed integer overflow (undefined behavior).

I agree. The comments could be misleading. They are gone.
I corrected the "time to overflow" statement. In my first estimate, I just forgot 10 of the 64 bits.
Thank you for your thorough look into the change.

openjdk · 2021-02-25T09:51:21Z

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

8261447: MethodInvocationCounters frequently run into overflow

Reviewed-by: thartmann, mdoerr, kvn, iveresov

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

a118185: 8261862: Expand discussion of rationale for BigDecimal equals/compareTo semantics
2d2ef08: 8262885: Shenandoah: FullGC prologue does not need to save/restore heap has_forwarded_object flag
1d2c1e6: 8248314: Parallel: Parallelize parallel full gc Adjust Roots phase
3d3eb5c: 8262368: wrong verifier message for bogus return type
6d3c858: 8259235: javac crashes while attributing super method invocation
bf90e85: 8262926: JDK-8260966 broke AIX build
54dfd79: 8262256: C2 intrinsincs should not modify IR when bailing out
0265ab6: 8262466: linux libsaproc/DwarfParser.cpp delete DwarfParser object in early return
c15801e: 8261142: AArch64: Incorrect instruction encoding when right-shifting vectors with shift amount equals to the element width
044e2a2: 8183569: Assert the same limits are used in parse_xss and globals.hpp
... and 189 more: https://git.openjdk.java.net/jdk/compare/8ba390d1e243c5ec2e637263fa44907b664e8ceb...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.

RealLucy · 2021-03-01T08:11:36Z

@TobiHartmann
@dholmes-ora
@veresov
May I kindly ask you to revisit your comments and potentially approve my changes? I believe I have addressed all you concerns and suggestions (as per my comment from Feb 16).
Thank you!
Lutz

TobiHartmann

This looks good to me.

RealLucy · 2021-03-01T08:31:40Z

Thank you for your review, Tobias!
I'll delay integration for a while to give David and Igor a chance to react.

dholmes-ora · 2021-03-01T22:54:15Z

Hi @RealLucy , I didn't do an actual review just made a passing comment.

RealLucy · 2021-03-02T08:34:29Z

@dholmes-ora OK then. I just didn't want to ignore anyone's opinion.
I plan to integrate the change before my EOB (GMT+1), provided there are no objections.

veresov · 2021-03-02T17:10:01Z

I left a comment a while ago about the unsigned int casts (in Method::print_invocation_count()) that I don't understand the reason for. Could you please comment on that?

vnkozlov

I have few comments.

vnkozlov · 2021-03-02T16:34:26Z

src/hotspot/cpu/x86/vtableStubs_x86_32.cpp

@@ -156,6 +156,7 @@ VtableStub* VtableStubs::create_itable_stub(int itable_index) {
  if (s == NULL) {
    return NULL;
  }
+


Why you did not update asm instruction to update nof_megamorphic_calls in this file?

The reason is plain simple: there is no incrementq() for x86_32. I could emulate that with a few lines like

address ctrAddr = (address)SharedRuntime::nof_megamorphic_calls_addr(); __ lea(rscratch1, ExternalAddress(ctrAddr)); __ addl(Address(rscratch1, 0), 1); __ adcl(Address(rscratch1, 4), 0);

Not sure if that would be desirable here. Just let me know. As is, the code just updates the less significant half of the 8-byte counter.

Okay, let keep as it is. Then revert this file back - the only change is new empty line.

vnkozlov · 2021-03-02T16:44:44Z

src/hotspot/share/oops/method.cpp

+  tty->print_cr ("  backedge_counter:             " UINT32_FORMAT_W(11) " %s", bec, addMsg);
+
+  if (method_data() != NULL) {
+    unsigned int dcc    = (unsigned int)method_data()->decompile_count();


decompile_count() returns uint why do cast and why you check decompile_count for overflow? It is very rare updated and limited by PerMethodRecompilationCutoff flag (400 by default):
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/methodData.hpp#L2391

That uint slipped my attention. And with the cutoff parameter, overflow is no issue. I can remove the cast and the check.

vnkozlov · 2021-03-02T17:05:06Z

src/hotspot/share/oops/method.cpp

+  // another factor of 2 before the counter values become meaningless.
+  // Print a "overflow" notification to create awareness.
+  const char* addMsg;
+  unsigned int maxInt = (1U<<31) - 1;


Why not use INT_MAX?

Will change.

I'd be better to change the logic to check if the counter is >= InvocationCounter::count_limit then it's in overflow.

With overflow I do not mean "counter overflow" as it is used to trigger compiler activities but plain simple "range of singed int exceeded". Should I use different wording? E.g. "counter in signed int overflow"?

Then it will never happen. These values come from InvocationCounter::count(). And it will never return a value > 2^31 - 1.

Sorry, it can return 2^31. Which would be an indication of a counter overflow (InvocationCounter::count_limit == 2^31). Your code is correct in both senses. It is a counter overflow and a signed int overflow.

Oops, my arithmetic is bad again. InvocationCounter::count_limit is 2^30. So, I don't think there ever going to be an overflow that you're looking for. The sign bit is always 0. Or am I missing something again? :)

RealLucy · 2021-03-02T17:35:18Z

@veresov I can't see your comment re. the casts. The only comment I see is re. the *64 suffixes.
Anyway, is your question/comment directly related to Vladimir's annotations? Or do you need further reasoning? Please let me know.

veresov · 2021-03-02T18:53:47Z

No it was a different question. I see my comments try clicking on the "Files changed" tab and scrolling down to method.cpp.
I also left a comment about your changes to compare_methods() I don't think it's correct.

RealLucy · 2021-03-02T19:25:26Z

Igor, I'm sorry, I can't see your comments. Neither those for method.cpp nor those for java.cpp. I checked the piper mail traffic as well. No mail from you after the *64 suffix comment. For simplicity, could you just paste your comment here, please? Or send them to me via mail (off-list, first.last at sap.com)?

veresov · 2021-03-02T19:48:07Z

Ok, odd. I've sent you an email.

veresov · 2021-02-11T21:14:04Z

src/hotspot/share/oops/method.cpp

+  // the overflow limit, we interpret the return value as unsigned int.
+  // This is ok because counters are unsigned by nature, and it gives us
+  // another factor of 2 before the counter values become meaningless.
+  // Print a "overflow" notification to create awareness.


What invocation_count() returns (which is currently equivalent to interpreter_invocation_count() btw) comes from the InvocationCounter::count() which cannot grow beyond 2^31, so all these counts are always positive. What exactly do these casts to unsigned do?

So, why do we need the casts to unsigned in this method?

When you increment (2^31-1), you get 2^31 which is 0x80000000. When interpreted as signed int, it is MIN_INT. I don't want that. I want to treat the value as positive number - what it actually is. There is no negative count!

I was trying to make a point that these counters are always < MAX_INT. InvocationCounter::count() shifts the counter right by 1, ensuring that the sign bit is 0. Method::{invocation, backedge, interpreter_invocation}_count() can also return InvocationCounter::count_limit, but this one is 2^30, which is also positive.

Slowly, but surely, we are coming to a common understanding. Thanks for educating me. I hadn't seen the range limitation for the counters. Now that I know, I recognise there is some knowledge in my almost faded memory.
OK, these three counters will never get dangerously close to 2^31-1. I will rework the section, remove some checks and casts. This will only happen tomorrow (Wednesday) which starts in 90 minutes in my time zone (GMT+1).

veresov · 2021-02-25T16:36:38Z

src/hotspot/share/runtime/java.cpp

-  return ((*b)->invocation_count() + (*b)->compiled_invocation_count())
-       - ((*a)->invocation_count() + (*a)->compiled_invocation_count());
+  return (int32_t)(((uint32_t)(*b)->invocation_count() + (*b)->compiled_invocation_count())
+                 - ((uint32_t)(*a)->invocation_count() + (*a)->compiled_invocation_count()));


Is this correct? The arithmetic look to be: (int32_t) (uint64_t - uint64_t). If the 64 values inside don't fit in 32, you'll get a negative number which would break the sorting logic.

I see that you've fixed the types since the last comment, but it think it's still broken (and has been before).
How about:

int64_t diff = ((*b)->compiled_invocation_count() - (*a)->compiled_invocation_count()) + ((*b)->invocation_count() - (*a)->invocation_count()); if (diff > 0) return 1; else if (diff < 0) return -1; else return 0;

It's kind of hacky too, because it assumes that compiled_invocation_count() are positive and didn't overflow. But at least we'd get rid of a possible overflow during summation. What do you think?

Right. As soon as there is overflow, the original formula doesn't do the trick either.
We can fix it as long as either (unsigned int)invocation_count() does not wrap around from 2^32-1 to 0. The entire expression is calculated as int64_t, protecting us from overflow for the next few years. If we then calculate the return value as you propose, we are good.

In your new code here casts to uint32_t are probably unnecessary.

veresov · 2021-03-02T18:50:24Z

src/hotspot/share/oops/method.cpp

+  // another factor of 2 before the counter values become meaningless.
+  // Print a "overflow" notification to create awareness.
+  const char* addMsg;
+  unsigned int maxInt = (1U<<31) - 1;


I'd be better to change the logic to check if the counter is >= InvocationCounter::count_limit then it's in overflow.

RealLucy · 2021-03-03T13:24:25Z

@veresov
@vnkozlov
Thank you again for the discussion yesterday. I have pushed the resulting changes for you to review. Awaiting your comments...

veresov

This looks good to me.

RealLucy · 2021-03-03T15:56:57Z

Thank you, Igor!

vnkozlov

Good.

RealLucy · 2021-03-03T20:03:18Z

Thank you, Vladimir!

RealLucy · 2021-03-03T20:04:00Z

/integrate

openjdk · 2021-03-03T20:04:55Z

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

75aa154: 8259267: Refactor LoaderLeak shell test as java test.
a118185: 8261862: Expand discussion of rationale for BigDecimal equals/compareTo semantics
2d2ef08: 8262885: Shenandoah: FullGC prologue does not need to save/restore heap has_forwarded_object flag
1d2c1e6: 8248314: Parallel: Parallelize parallel full gc Adjust Roots phase
3d3eb5c: 8262368: wrong verifier message for bogus return type
6d3c858: 8259235: javac crashes while attributing super method invocation
bf90e85: 8262926: JDK-8260966 broke AIX build
54dfd79: 8262256: C2 intrinsincs should not modify IR when bailing out
0265ab6: 8262466: linux libsaproc/DwarfParser.cpp delete DwarfParser object in early return
c15801e: 8261142: AArch64: Incorrect instruction encoding when right-shifting vectors with shift amount equals to the element width
... and 190 more: https://git.openjdk.java.net/jdk/compare/8ba390d1e243c5ec2e637263fa44907b664e8ceb...master

Your commit was automatically rebased without conflicts.

Pushed as commit 268d9b7.

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

openjdk bot added rfr Pull request is ready for review hotspot hotspot-dev@openjdk.org labels Feb 10, 2021

RealLucy changed the title ~~JDK-8261447: MethodInvocationCounters frequently run into overflow~~ 8261447: MethodInvocationCounters frequently run into overflow Feb 10, 2021

TobiHartmann suggested changes Feb 11, 2021

View reviewed changes

openjdk bot added the serviceability serviceability-dev@openjdk.org label Feb 12, 2021

RealLucy added 3 commits February 16, 2021 16:02

JDK-8261447: MethodInvocationCounters frequently run into overflow

f350bc9

8261447: requested changes by TobiHartmann

de3b5ba

expand remaining counters to 64-bit, remove 64 duffix

0a99ee4

RealLucy force-pushed the JDK-8261447 branch from 67fb3f7 to 273d55c Compare February 16, 2021 15:15

openjdk bot removed the rfr Pull request is ready for review label Feb 16, 2021

RealLucy force-pushed the JDK-8261447 branch from 273d55c to 0a99ee4 Compare February 16, 2021 15:25

openjdk bot added the rfr Pull request is ready for review label Feb 16, 2021

RealLucy added 3 commits February 16, 2021 22:55

cleaning up the remaining mess

f68e547

no incrementq for x86_32

faab64b

update copyright year

0f220ee

dholmes-ora reviewed Feb 18, 2021

View reviewed changes

TheRealMDoerr suggested changes Feb 24, 2021

View reviewed changes

comment changes requested by TheRealMDoerr

e8af119

TheRealMDoerr approved these changes Feb 25, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Feb 25, 2021

TobiHartmann approved these changes Mar 1, 2021

View reviewed changes

vnkozlov reviewed Mar 2, 2021

View reviewed changes

veresov suggested changes Mar 2, 2021

View reviewed changes

RealLucy added 2 commits March 3, 2021 13:26

Changes requested by veresov

5c27640

revert copyright change to get rid of unchanged file

0faea5a

veresov approved these changes Mar 3, 2021

View reviewed changes

vnkozlov approved these changes Mar 3, 2021

View reviewed changes

openjdk bot closed this Mar 3, 2021

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 Mar 3, 2021

8261447: MethodInvocationCounters frequently run into overflow #2511

8261447: MethodInvocationCounters frequently run into overflow #2511

Conversation

RealLucy commented Feb 10, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Download

bridgekeeper bot commented Feb 10, 2021

RealLucy commented Feb 10, 2021

openjdk bot commented Feb 10, 2021

mlbridge bot commented Feb 10, 2021 • edited Loading

Webrevs

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

RealLucy commented Feb 11, 2021

vnkozlov commented Feb 11, 2021

veresov commented Feb 11, 2021

RealLucy commented Feb 12, 2021

RealLucy commented Feb 12, 2021

openjdk bot commented Feb 12, 2021

openjdk bot commented Feb 15, 2021

RealLucy commented Feb 15, 2021

RealLucy commented Feb 17, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mlbridge bot commented Feb 18, 2021

TheRealMDoerr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RealLucy Feb 25, 2021 • edited Loading

Choose a reason for hiding this comment

openjdk bot commented Feb 25, 2021 • edited Loading

RealLucy commented Mar 1, 2021

TobiHartmann left a comment

Choose a reason for hiding this comment

RealLucy commented Mar 1, 2021

dholmes-ora commented Mar 1, 2021

RealLucy commented Mar 2, 2021

veresov commented Mar 2, 2021

vnkozlov 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

RealLucy commented Mar 2, 2021

veresov commented Mar 2, 2021

RealLucy commented Mar 2, 2021

veresov commented Mar 2, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

veresov Mar 2, 2021 • edited Loading

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

RealLucy commented Mar 3, 2021

veresov left a comment

Choose a reason for hiding this comment

RealLucy commented Mar 3, 2021

vnkozlov left a comment

Choose a reason for hiding this comment

RealLucy commented Mar 3, 2021

RealLucy commented Feb 10, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Feb 10, 2021 •

edited

Loading

RealLucy Feb 25, 2021 •

edited

Loading

openjdk bot commented Feb 25, 2021 •

edited

Loading

veresov commented Mar 2, 2021 •

edited

Loading

veresov Mar 2, 2021 •

edited

Loading