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

8261447: MethodInvocationCounters frequently run into overflow #2511

Closed
wants to merge 9 commits into from

Conversation

@RealLucy
Copy link
Contributor

@RealLucy RealLucy commented Feb 10, 2021

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

Download

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Feb 10, 2021

👋 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
Copy link
Contributor Author

@RealLucy RealLucy commented Feb 10, 2021

/cc hotspot-dev

@openjdk
Copy link

@openjdk openjdk bot commented Feb 10, 2021

@RealLucy
The hotspot label was successfully added.

@mlbridge
Copy link

@mlbridge mlbridge bot commented Feb 10, 2021

Webrevs

@RealLucy RealLucy changed the title JDK-8261447: MethodInvocationCounters frequently run into overflow 8261447: MethodInvocationCounters frequently run into overflow Feb 10, 2021
@@ -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); }
Copy link
Member

@TobiHartmann TobiHartmann Feb 11, 2021

Choose a reason for hiding this comment

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

compiled_invocation_counter_offset() looks unused.

Copy link
Contributor Author

@RealLucy RealLucy Feb 11, 2021

Choose a reason for hiding this comment

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

Correct. Removed.

#else
// for PrintMethodData in a product build
int compiled_invocation_count() const { return 0; }
int compiled_invocation_count() const { return 0; }
Copy link
Member

@TobiHartmann TobiHartmann Feb 11, 2021

Choose a reason for hiding this comment

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

compiled_invocation_count() looks unused.

Copy link
Contributor Author

@RealLucy RealLucy Feb 11, 2021

Choose a reason for hiding this comment

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

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

#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.
Copy link
Member

@TobiHartmann TobiHartmann Feb 11, 2021

Choose a reason for hiding this comment

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

Why not update the SA code to access 64 bit?

Copy link
Contributor Author

@RealLucy RealLucy Feb 11, 2021

Choose a reason for hiding this comment

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

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
Copy link
Contributor Author

@RealLucy RealLucy commented Feb 11, 2021

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

@vnkozlov
Copy link
Contributor

@vnkozlov vnkozlov commented Feb 11, 2021

@veresov please review these changes

@veresov
Copy link
Contributor

@veresov veresov commented Feb 11, 2021

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
Copy link
Contributor Author

@RealLucy RealLucy commented Feb 12, 2021

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
Copy link
Contributor Author

@RealLucy RealLucy commented Feb 12, 2021

/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
Copy link

@openjdk openjdk bot commented Feb 12, 2021

@RealLucy
The serviceability label was successfully added.

@openjdk
Copy link

@openjdk openjdk bot commented Feb 15, 2021

⚠️ @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
Copy link
Contributor Author

@RealLucy RealLucy commented Feb 15, 2021

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.

@openjdk openjdk bot removed the rfr label Feb 16, 2021
@openjdk openjdk bot added the rfr label Feb 16, 2021
@RealLucy
Copy link
Contributor Author

@RealLucy RealLucy commented Feb 17, 2021

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

  1. 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.

  2. 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

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
Copy link
Member

@dholmes-ora dholmes-ora Feb 18, 2021

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

@RealLucy RealLucy Feb 18, 2021

Choose a reason for hiding this comment

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

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
Copy link

@mlbridge mlbridge bot commented Feb 18, 2021

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

Copy link
Contributor

@TheRealMDoerr TheRealMDoerr left a comment

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.

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.
Copy link
Contributor

@TheRealMDoerr TheRealMDoerr Feb 24, 2021

Choose a reason for hiding this comment

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

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).

Copy link
Contributor Author

@RealLucy RealLucy Feb 25, 2021

Choose a reason for hiding this comment

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

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
Copy link

@openjdk openjdk bot commented Feb 25, 2021

@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.

@openjdk openjdk bot added the ready label Feb 25, 2021
@RealLucy
Copy link
Contributor Author

@RealLucy RealLucy commented Mar 1, 2021

@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

Copy link
Member

@TobiHartmann TobiHartmann left a comment

This looks good to me.

@RealLucy
Copy link
Contributor Author

@RealLucy RealLucy commented Mar 1, 2021

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

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Mar 1, 2021

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

@RealLucy
Copy link
Contributor Author

@RealLucy RealLucy commented Mar 2, 2021

@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
Copy link
Contributor

@veresov veresov commented Mar 2, 2021

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?

Copy link
Contributor

@vnkozlov vnkozlov left a comment

I have few comments.

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

Copy link
Contributor

@vnkozlov vnkozlov Mar 2, 2021

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

@RealLucy RealLucy Mar 2, 2021

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@vnkozlov vnkozlov Mar 2, 2021

Choose a reason for hiding this comment

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

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

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();
Copy link
Contributor

@vnkozlov vnkozlov Mar 2, 2021

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

@RealLucy RealLucy Mar 2, 2021

Choose a reason for hiding this comment

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

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

// 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;
Copy link
Contributor

@vnkozlov vnkozlov Mar 2, 2021

Choose a reason for hiding this comment

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

Why not use INT_MAX?

Copy link
Contributor Author

@RealLucy RealLucy Mar 2, 2021

Choose a reason for hiding this comment

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

Will change.

Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

@RealLucy RealLucy Mar 2, 2021

Choose a reason for hiding this comment

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

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"?

Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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

Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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
Copy link
Contributor Author

@RealLucy RealLucy commented Mar 2, 2021

@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
Copy link
Contributor

@veresov veresov commented Mar 2, 2021

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
Copy link
Contributor Author

@RealLucy RealLucy commented Mar 2, 2021

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
Copy link
Contributor

@veresov veresov commented Mar 2, 2021

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

// 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.
Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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?

Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

@RealLucy RealLucy Mar 2, 2021

Choose a reason for hiding this comment

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

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!

Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

@RealLucy RealLucy Mar 2, 2021

Choose a reason for hiding this comment

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

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).

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()));
Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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?

Copy link
Contributor Author

@RealLucy RealLucy Mar 2, 2021

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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

// 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;
Copy link
Contributor

@veresov veresov Mar 2, 2021

Choose a reason for hiding this comment

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

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

@RealLucy
Copy link
Contributor Author

@RealLucy RealLucy commented Mar 3, 2021

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

veresov
veresov approved these changes Mar 3, 2021
Copy link
Contributor

@veresov veresov left a comment

This looks good to me.

@RealLucy
Copy link
Contributor Author

@RealLucy RealLucy commented Mar 3, 2021

Thank you, Igor!

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Good.

@RealLucy
Copy link
Contributor Author

@RealLucy RealLucy commented Mar 3, 2021

Thank you, Vladimir!

@RealLucy
Copy link
Contributor Author

@RealLucy RealLucy commented Mar 3, 2021

/integrate

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

@openjdk openjdk bot commented Mar 3, 2021

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment