8339648: ZGC: Division by zero in rule_major_allocation_rate #20888

MBaesken · 2024-09-06T10:26:19Z

The HS jtreg test gc/stringdedup/TestStringDeduplicationAgeThreshold_ZGenerational
shows this error when running with ubsan enabled

src/hotspot/share/gc/z/zDirector.cpp:491:74: runtime error: division by zero
#0 0x7f09886401d4 in rule_major_allocation_rate src/hotspot/share/gc/z/zDirector.cpp:491
#1 0x7f09886401d4 in start_gc src/hotspot/share/gc/z/zDirector.cpp:822
#2 0x7f09886401d4 in ZDirector::run_thread() src/hotspot/share/gc/z/zDirector.cpp:912
#3 0x7f098c1404e8 in ZThread::run_service() src/hotspot/share/gc/z/zThread.cpp:29
#4 0x7f09897cac19 in ConcurrentGCThread::run() src/hotspot/share/gc/shared/concurrentGCThread.cpp:48
#5 0x7f098bb46b0a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
#6 0x7f098b1a9881 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:858

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8339648: ZGC: Division by zero in rule_major_allocation_rate (Enhancement - P4)

Reviewers

Axel Boldt-Christmas (@xmas92 - Reviewer)
Thomas Schatzl (@tschatzl - Reviewer) Review applies to 21fe3ca7
Lutz Schmidt (@RealLucy - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/20888/head:pull/20888
$ git checkout pull/20888

Update a local copy of the PR:
$ git checkout pull/20888
$ git pull https://git.openjdk.org/jdk.git pull/20888/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 20888

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/20888.diff

Webrev

Link to Webrev Comment

bridgekeeper · 2024-09-06T10:27:04Z

👋 Welcome back mbaesken! 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 · 2024-09-06T10:27:24Z

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

8339648: ZGC: Division by zero in rule_major_allocation_rate

Reviewed-by: aboldtch, lucy, tschatzl

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

c6721a0: 8340009: Improve the output from assert_different_registers
7834662: 8340119: Remove oopDesc::size_might_change()
10050a7: 8332442: C2: refactor Mod cases in Compile::final_graph_reshaping_main_switch()
7849f25: 8340184: Bug in CompressedKlassPointers::is_in_encodable_range
a4cf191: 8339793: Fix incorrect APX feature enabling with -XX:-UseAPX
3e03e66: 8340176: Replace usage of -noclassgc with -Xnoclassgc in test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java
99d7185: 8340144: C1: remove unused Compilation::_max_spills
418bb42: 8340073: Support "%z" time zone abbreviation format in TZ files
b26645f: 8339883: Open source several AWT/2D related tests
858b4f1: 8339960: GenShen: Fix inconsistencies in generational Shenandoah behavior
... and 110 more: https://git.openjdk.org/jdk/compare/a35fd3861044bdb8ddae378cb666b3d2e549a8c8...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 · 2024-09-06T10:27:58Z

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

mlbridge · 2024-09-06T10:32:01Z

Webrevs

MBaesken · 2024-09-06T10:36:12Z

So we should avoid the division in case the divisor is zero and rewrite the coding a bit.

8339648: ZGC: Division by zero in rule_major_allocation_rate

xmas92 · 2024-09-06T12:44:52Z

src/hotspot/share/gc/z/zDirector.cpp

+  bool old_garbage_is_cheaper = true;
+  if (reclaimed_per_old_gc != 0) {
+    const double current_old_gc_time_per_bytes_freed = double(old_gc_time) / double(reclaimed_per_old_gc);
+    old_garbage_is_cheaper = current_old_gc_time_per_bytes_freed < current_young_gc_time_per_bytes_freed;
+  }


Ending up with old_garbage_is_cheaper == true when reclaimed_per_old_gc == 0 seems wrong to me.

Division by 0.0 is weird in C++. Do we even build for systems where it would not be supported. But regardless to me I feel like the change here should be more like:

- const double current_old_gc_time_per_bytes_freed = double(old_gc_time) / double(reclaimed_per_old_gc); + const double current_old_gc_time_per_bytes_freed = reclaimed_per_old_gc == 0 ? std::numeric_limits<double>::infinity : double(old_gc_time) / double(reclaimed_per_old_gc);

Which is the behaviour I expect us to currently have, given that old_gc_time should be a positive number (>0.0). The !stats._old_stats._cycle._is_time_trustable check above should protect against 0.0.

I expect that this division we see happens when we have run a warmup major collection which did no reclaim any memory. And this change would trigger us to try and promote a minor collection to a major collection.

I am no expert on our supported platforms matrix w.r.t. floating numbers and std::numeric_limits<T>::has_infinity.

MBaesken · 2024-09-09T07:43:12Z

looks like for clang
https://bugs.llvm.org/show_bug.cgi?id=17000#c1
the float division by 0 became defined behavior, but it might be different for other compilers. I think it depends not only on the platform but also on the compiler. See the discussion here https://stackoverflow.com/questions/42926763/the-behaviour-of-floating-point-division-by-zero

MBaesken · 2024-09-09T11:38:48Z

Hi Axel, I adjusted the coding following your suggestion.
Btw. is there maybe already somewhere a template function doing that division handling divisor 0? Probably it is not the only place in the codebase where this can happen ?

xmas92

I am fine with this change. But I am not 100% about the use of std::numeric_limits<double>::infinity(). Maybe someone else can chime in.

Not sure if there are any other places we have expect division by zero to result in infinity.

MBaesken · 2024-09-11T11:10:48Z

I am fine with this change. But I am not 100% about the use of std::numeric_limits<double>::infinity(). Maybe someone else can chime in.

Not sure if there are any other places we have expect division by zero to result in infinity.

Thanks for the review !

Seems this exists since c++11 https://en.cppreference.com/w/cpp/types/numeric_limits/infinity so usage should be okay.
We also find it in libsimdsort (linux only in OpenJDK however) https://github.com/openjdk/jdk/blob/master/src/java.base/linux/native/libsimdsort/xss-common-includes.h#L47

tschatzl

Lgtm but see the additional comment.

tschatzl · 2024-09-13T08:31:43Z

src/hotspot/share/gc/z/zDirector.cpp

@@ -488,7 +488,7 @@ static bool rule_major_allocation_rate(const ZDirectorStats& stats) {

  // Calculate the GC cost for each reclaimed byte
  const double current_young_gc_time_per_bytes_freed = double(young_gc_time) / double(reclaimed_per_young_gc);


Could this division have the same issue?

Yes, it could if no memory has been reclaimed at all (since the VM started). Similar issues would occur in the call to calculate_extra_young_gc_time below. And there I think the problem is even worse, because we might end up with inf - inf == -nan.

The case where we have performed a major collection and no young collection has reclaim any memory seems like a very degenerate situation. The solution is probably to handle that case separately, and not try to adapt the current heuristics to handle the extreme values.

RealLucy · 2024-09-16T08:15:38Z

src/hotspot/share/gc/z/zDirector.cpp

@@ -488,7 +488,7 @@ static bool rule_major_allocation_rate(const ZDirectorStats& stats) {

  // Calculate the GC cost for each reclaimed byte
  const double current_young_gc_time_per_bytes_freed = double(young_gc_time) / double(reclaimed_per_young_gc);
-  const double current_old_gc_time_per_bytes_freed = double(old_gc_time) / double(reclaimed_per_old_gc);
+  const double current_old_gc_time_per_bytes_freed = reclaimed_per_old_gc == 0 ? std::numeric_limits<double>::infinity() : double(old_gc_time) / double(reclaimed_per_old_gc);


How about using some parentheses? To my understanding, the division has a higher precedence than the ternary conditional expression. See: https://en.cppreference.com/w/cpp/language/operator_precedence

I do not mind parentheses. But ternary are the lowest precedence (if you do not count the , which I would almost always say is wrong to use without a surrounding () / [] / {}), so to me it seems superfluous.

Just to clarify the intent of this code is what we are getting with a higher precedence on division. That is:

const double current_old_gc_time_per_bytes_freed = ((reclaimed_per_old_gc == 0) ? (std::numeric_limits<double>::infinity()) : (double(old_gc_time) / double(reclaimed_per_old_gc)));

Side Note:
I also think I prefer immediately invoked lambdas when the ternaries get this long.

const double current_old_gc_time_per_bytes_freed = [&]() { if (reclaimed_per_old_gc == 0) { return std::numeric_limits<double>::infinity(); } return double(old_gc_time) / double(reclaimed_per_old_gc); }();

src/hotspot/share/gc/z/zDirector.cpp

+  const double current_old_gc_time_per_bytes_freed = ((reclaimed_per_old_gc == 0) ? (std::numeric_limits<double>::infinity())
+                                                                                  : (double(old_gc_time) / double(reclaimed_per_old_gc)));


RealLucy

Looks good now. Thanks

MBaesken · 2024-09-17T11:58:05Z

Thanks for the reviews !

/integrate

openjdk · 2024-09-17T11:58:58Z

Going to push as commit 80db6e7.
Since your change was applied there have been 122 commits pushed to the master branch:

269cd38: 8338566: Lazy creation of exception instances is not thread safe
8b6e277: 8340273: Remove CounterHalfLifeTime
c6721a0: 8340009: Improve the output from assert_different_registers
7834662: 8340119: Remove oopDesc::size_might_change()
10050a7: 8332442: C2: refactor Mod cases in Compile::final_graph_reshaping_main_switch()
7849f25: 8340184: Bug in CompressedKlassPointers::is_in_encodable_range
a4cf191: 8339793: Fix incorrect APX feature enabling with -XX:-UseAPX
3e03e66: 8340176: Replace usage of -noclassgc with -Xnoclassgc in test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java
99d7185: 8340144: C1: remove unused Compilation::_max_spills
418bb42: 8340073: Support "%z" time zone abbreviation format in TZ files
... and 112 more: https://git.openjdk.org/jdk/compare/a35fd3861044bdb8ddae378cb666b3d2e549a8c8...master

Your commit was automatically rebased without conflicts.

openjdk · 2024-09-17T11:59:05Z

@MBaesken Pushed as commit 80db6e7.

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

JDK-8339648

c66c089

openjdk bot changed the title ~~JDK-8339648: ZGC: Division by zero in rule_major_allocation_rate~~ 8339648: ZGC: Division by zero in rule_major_allocation_rate Sep 6, 2024

openjdk bot added the rfr Pull request is ready for review label Sep 6, 2024

openjdk bot added the hotspot-gc [email protected] label Sep 6, 2024

github-actions bot pushed a commit to dougxc/openjdk-pr-canary that referenced this pull request Sep 6, 2024

test record for openjdk/jdk#20888

09dcc40

8339648: ZGC: Division by zero in rule_major_allocation_rate

xmas92 reviewed Sep 6, 2024

View reviewed changes

Adjust division following suggestion by xmas

21fe3ca

xmas92 approved these changes Sep 11, 2024

View reviewed changes

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

tschatzl approved these changes Sep 13, 2024

View reviewed changes

RealLucy suggested changes Sep 16, 2024

View reviewed changes

add parentheses

6902026

openjdk bot removed the ready Pull request is ready to be integrated label Sep 16, 2024

xmas92 suggested changes Sep 16, 2024

View reviewed changes

adjust parentheses

7ecdb37

xmas92 approved these changes Sep 17, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Sep 17, 2024

RealLucy approved these changes Sep 17, 2024

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Sep 17, 2024

openjdk bot closed this Sep 17, 2024

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 17, 2024

xmas92 mentioned this pull request Oct 2, 2024

8336911: ZGC: Division by zero in heuristics after JDK-8332717 #21304

Closed

3 tasks

xmas92 mentioned this pull request Nov 19, 2024

8344414: ZGC: Another division by zero in rule_major_allocation_rate #22228

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8339648: ZGC: Division by zero in rule_major_allocation_rate #20888

8339648: ZGC: Division by zero in rule_major_allocation_rate #20888

MBaesken commented Sep 6, 2024 •

edited by openjdk bot

Loading

bridgekeeper bot commented Sep 6, 2024

openjdk bot commented Sep 6, 2024 •

edited

Loading

openjdk bot commented Sep 6, 2024

mlbridge bot commented Sep 6, 2024 •

edited

Loading

MBaesken commented Sep 6, 2024

xmas92 Sep 6, 2024 •

edited

Loading

MBaesken commented Sep 9, 2024

MBaesken commented Sep 9, 2024

xmas92 left a comment

MBaesken commented Sep 11, 2024

tschatzl left a comment

tschatzl Sep 13, 2024

xmas92 Sep 13, 2024

xmas92 Sep 13, 2024

RealLucy Sep 16, 2024

xmas92 Sep 16, 2024

This comment was marked as resolved.

RealLucy left a comment

MBaesken commented Sep 17, 2024

openjdk bot commented Sep 17, 2024

openjdk bot commented Sep 17, 2024

		@@ -488,7 +488,7 @@ static bool rule_major_allocation_rate(const ZDirectorStats& stats) {

		// Calculate the GC cost for each reclaimed byte
		const double current_young_gc_time_per_bytes_freed = double(young_gc_time) / double(reclaimed_per_young_gc);

		const double current_old_gc_time_per_bytes_freed = ((reclaimed_per_old_gc == 0) ? (std::numeric_limits<double>::infinity())
		: (double(old_gc_time) / double(reclaimed_per_old_gc)));

8339648: ZGC: Division by zero in rule_major_allocation_rate #20888

8339648: ZGC: Division by zero in rule_major_allocation_rate #20888

Conversation

MBaesken commented Sep 6, 2024 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

Webrev

bridgekeeper bot commented Sep 6, 2024

openjdk bot commented Sep 6, 2024 • edited Loading

openjdk bot commented Sep 6, 2024

mlbridge bot commented Sep 6, 2024 • edited Loading

Webrevs

MBaesken commented Sep 6, 2024

xmas92 Sep 6, 2024 • edited Loading

Choose a reason for hiding this comment

MBaesken commented Sep 9, 2024

MBaesken commented Sep 9, 2024

xmas92 left a comment

Choose a reason for hiding this comment

MBaesken commented Sep 11, 2024

tschatzl left a comment

Choose a reason for hiding this comment

tschatzl Sep 13, 2024

Choose a reason for hiding this comment

xmas92 Sep 13, 2024

Choose a reason for hiding this comment

xmas92 Sep 13, 2024

Choose a reason for hiding this comment

RealLucy Sep 16, 2024

Choose a reason for hiding this comment

xmas92 Sep 16, 2024

Choose a reason for hiding this comment

This comment was marked as resolved.

RealLucy left a comment

Choose a reason for hiding this comment

MBaesken commented Sep 17, 2024

openjdk bot commented Sep 17, 2024

openjdk bot commented Sep 17, 2024

MBaesken commented Sep 6, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Sep 6, 2024 •

edited

Loading

mlbridge bot commented Sep 6, 2024 •

edited

Loading

xmas92 Sep 6, 2024 •

edited

Loading