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

8248411: [aarch64] Insufficient error handling when CodeBuffer is exhausted #765

Closed
wants to merge 1 commit into from
Closed

Conversation

ghost
Copy link

@ghost ghost commented Oct 20, 2020

Trampoline call generation (in the macro-assembler) may run out of CodeBuffer space without the proper error handling, resulting in asserts such as:

#  Internal Error (.../open/src/hotspot/share/asm/codeBuffer.hpp:198), pid=845, tid=859
#  assert(allocates2(pc)) failed: relocation addr must be in this section

This update extends the error handling for such error cases to cover all uses of trampoline_call(), direct and indirect. Failure registration/recording is retained in the "aarch64.ad" file.


Progress

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

Testing

Linux x64 Windows x64 macOS x64
Build ✔️ (5/5 passed) ✔️ (2/2 passed) ✔️ (2/2 passed)
Test (tier1) ✔️ (9/9 passed) ✔️ (9/9 passed) ✔️ (9/9 passed)

Issue

  • JDK-8248411: [aarch64] Insufficient error handling when CodeBuffer is exhausted

Reviewers

Download

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

@bridgekeeper
Copy link

bridgekeeper bot commented Oct 20, 2020

👋 Welcome back phedlin! 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 openjdk bot added the rfr Pull request is ready for review label Oct 20, 2020
@openjdk
Copy link

openjdk bot commented Oct 20, 2020

@phedlin 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 pull request command.

@openjdk openjdk bot added the hotspot hotspot-dev@openjdk.org label Oct 20, 2020
@mlbridge
Copy link

mlbridge bot commented Oct 20, 2020

Webrevs

@ghost
Copy link
Author

ghost commented Oct 20, 2020

Testing tier1-3
Repeated testing with hs-tier1-3 using -XX:+StressCodeBuffers.
Repeated testing with jtreg:compiler/profiling/spectrapredefineclass/Launcher.java using -XX:+StressCodeBuffers.

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Choose a reason for hiding this comment

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

output.cpp change looks fine.
aarch64 changes should be reviewed who familiar.

@openjdk
Copy link

openjdk bot commented Oct 21, 2020

@phedlin The label aarch64-port is not a valid label. These labels are valid:

  • serviceability
  • hotspot
  • sound
  • hotspot-compiler
  • kulla
  • i18n
  • shenandoah
  • jdk
  • javadoc
  • 2d
  • security
  • swing
  • hotspot-runtime
  • jmx
  • build
  • nio
  • beans
  • core-libs
  • compiler
  • net
  • hotspot-gc
  • hotspot-jfr
  • awt

Copy link
Contributor

@adinn adinn left a comment

Choose a reason for hiding this comment

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

The AArch64 changes are ok.
<rant> I am not at all keen on the many format-only changes that are included in this patch since they introduce a lot of changed lines for the sole and rather specious benefit of adherence to a questionable orthographic authority. That's especially so with the relatively unscryable (sic) changes in output.cpp that modify declarations of the form Foo *foo to Foo* foo. One is initially left wondering what has changed only, at penny-drop, to replace that feeling with equal wonder as to why it was worth bothering, especially as there remain many thousands more such editorial opportunities. Meanwhile the substantive signal that constitutes the real patch is lost amid this noise. Of course, you may continue tilting at this windmill if you really wish to.</rant>

@openjdk
Copy link

openjdk bot commented Oct 21, 2020

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

8248411: [aarch64] Insufficient error handling when CodeBuffer is exhausted

Reviewed-by: adinn

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

  • da97ab5: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer
  • 7e26404: 8255000: C2: Unify IGVN processing when loop opts are over
  • 27230fa: 8255026: C2: Miscellaneous cleanups in Compile and PhaseIdealLoop code
  • c107178: 8253964: [Graal] UnschedulableGraphTest#test01fails with expected:<4> but was:<3>
  • bd45191: 8255065: Zero: accessor_entry misses the IRIW case
  • 2a06335: 8254785: compiler/graalunit/HotspotTest.java failed with "missing Graal intrinsics for: java/lang/StringLatin1.indexOfChar([BIII)I"
  • 1b7ddeb: 8254976: Re-enable swing jtreg tests which were broken due to samevm mode
  • 2e510e0: 8255043: Incorrectly styled copyright text
  • 6bd05b1: 8255074: sun.nio.fs.WindowsPath::getPathForWin32Calls synchronizes on String object
  • 9e9f5e6: 8017179: [macosx] list1 and list2 vistble item isn't desired
  • ... and 91 more: https://git.openjdk.java.net/jdk/compare/1742c44ac97b644d90c7f2115edbb5ca507ca731...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 Pull request is ready to be integrated label Oct 21, 2020
@theRealAph
Copy link
Contributor

theRealAph commented Oct 21, 2020

The AArch64 changes are ok.
I am not at all keen on the many format-only changes that are included in this patch since they introduce a lot of changed lines for the sole and rather specious benefit of adherence to a questionable orthographic authority. That's especially so with the relatively unscryable (sic) changes in output.cpp that modify declarations of the form Foo *foo to Foo* foo. One is initially left wondering what has changed only, at penny-drop, to replace that feeling with equal wonder as to why it was worth bothering, especially as there remain many thousands more such editorial opportunities. Meanwhile the substantive signal that constitutes the real patch is lost amid this noise. Of course, you may continue tilting at this windmill if you really wish to.

I agree. I'm happy enough with code being tidied up as we go along, but not with a patch like this one, where it's not even clear that the result is an improvement. Also, it doesn't make sense to "tidy up" code that is nothing to do with the patch.

Changing Foo *foo to Foo* foo is simply wrong. The * operator binds to the right, so something like int* a, b looks like a and b are pointers; they're not. That's why we write int *a, b : we should be writing for the reader.

@ghost
Copy link
Author

ghost commented Oct 22, 2020

May I suggest the following to lessen the burden of mundane white-space edits.

image

@ghost
Copy link
Author

ghost commented Oct 22, 2020

So what about the Foo* p vs Foo *p? In short, I totally disagree. Foo* p supports the reading of p as Foo-pointer (or int-pointer, or void-pointer) which also emphasises the fact that the base type is vital to the operations available through/on p. This view is obscured by Foo *p (or Foo p, *q), suggesting "a pointer" is a more general concept, free of semantics imposed by its base type. For the same reason, I write int* f() not int *f(), not ever. And "we" don't write int* p, q nor do "we" write int p, *q since not only need pointers be initialised but more importantly, it's a truly bad idea to introduce different semantic entities in a single declaration. "We" write code to be read, and understood, by humans.

May I also offer the following explanation to why the * (pointer-decl) operator binds to the right. Is it perhaps due to the fact that the original K&R C-syntax predates the first official standard by roughly 20 years, syntax picked-up from the B language (which only had one "pointer type", the address of an array, and no type-system), that we use the unary prefix "indirection operator"; *v ?

In any case, I thank you both for reviewing the code (well, I guess 'aph' didn't actually review) even though it seems to upset the two of you, and despite the fact that I don't find the ranting particularly constructive.

Thanks also to Vladimir.

@ghost
Copy link
Author

ghost commented Oct 22, 2020

/integrate

@openjdk openjdk bot closed this Oct 22, 2020
@openjdk 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 Oct 22, 2020
@openjdk
Copy link

openjdk bot commented Oct 22, 2020

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

  • 4634dbe: 8223312: Utilize handshakes instead of is_thread_fully_suspended
  • cc50c8d: 8255196: Remove unused G1FullGCCompactionPoint::merge()
  • ae72b52: 8255047: Add HotSpot UseDebuggerErgo flags
  • 211bb62: 8255124: KeepAliveStreamCleaner may crash with java.lang.IllegalMonitorStateException: current thread is not owner
  • 299e115: 8198395: Test javax/swing/plaf/metal/MetalLookAndFeel/Test8039750.java fails in mach5
  • a5b7bc5: 7156347: javax/swing/JList/6462008/bug6462008.java fails
  • b25d894: 8252204: AArch64: Implement SHA3 accelerator/intrinsic
  • 7d3d4da: 8240709: Enable javax/swing/UI/UnninstallUIMemoryLeaks/UnninstallUIMemoryLeaks.java on all L&F
  • 5d26229: 8255174: Vector API unit tests for missed public api code coverage
  • b9186be: 6606767: resexhausted00[34] fail assert(!thread->owns_locks(), "must release all locks when leaving VM")
  • ... and 116 more: https://git.openjdk.java.net/jdk/compare/1742c44ac97b644d90c7f2115edbb5ca507ca731...master

Your commit was automatically rebased without conflicts.

Pushed as commit f279ddf.

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

@theRealAph
Copy link
Contributor

In any case, I thank you both for reviewing the code (well, I guess 'aph' didn't actually review) even though it seems to upset the two of you, and despite the fact that I don't find the ranting particularly constructive.

We're not upset, at least I'm not, but I don't think we should change existing code based on preference. In other words, despite the fact that I have a strong preference, I don't go round changing instances of int* p to int *p when I see them, and I don't think you should either. HotSpot doesn't have a history of micro-managing code layout, and that's a good thing. One consequence of this is minor local variations.

Also, churn is bad, and in this case we have a bunch of edits to a file which has nothing to do with the bug being fixed. It's taken me a while to be sure, but I can find no changes to opto/output.cpp except layout. This complicates the diffs for the reviewer and makes future diff searches harder for people in the future. Sure, if layout is unusual to the point of being misleading,we should change it.

May I also offer the following explanation to why the * (pointer-decl) operator binds to the right. Is it perhaps due to the fact that the original K&R C-syntax predates the first official standard by roughly 20 years

The reason for the syntax is that Richie had the idea that "declaration follows use". http://www.gotw.ca/publications/c_family_interview.htm

@adinn
Copy link
Contributor

adinn commented Oct 23, 2020

Hi Patrick. You mistake my intention as well as Andrew's. I also am far from upset. The jist of my 'rant' was actually an argument, not an emotional reaction; the rant tags were merely offered by way of levity. I guess I actually need to reiterate the argument straight to address the concern both Andrew and I share.

My purpose was not to crusade against your preferred orthography with a complementary jihad (n.b. I am as agnostic about asterisk placement as I am about which end of a boiled egg to attack). The point I thought I had rendered clear (but clearly not clear enough) is that orthographic crusades to correct perceived errors across the code base are worse than futile. Offences to partisan pedantry aside, they serve to introduce noise into the code base, the result being to mask the all-important signal i.e. what changes were actually needed to fix an issue. That outcome is a red flag for any reviewer/maintainer not just because we have to decipher that signal at review time, but also because it is problematic 1) at backport time and 2) when debugging, diagnosing and fixing problems in the same or closely related parts of the code base and backporting their patches.

Of course, you are correct when you point out that this noise can be filtered in the github interface. However, that does not remove the noise from the code base nor does it mean such redress is available from all the other tools -- including and most especially the human eye -- that have to process the code base when performing the review and susbequent review and maintenance tasks. Webrevs, file version diffs, git blame reports, conflict free patch backports all work better and require less human intervention if what are essentially irrelevant changes are avoided. That's advice that has been offered many times by other reviewers and that I repeat based on experience not ideology. I consider it far more valuable, albeit more boringly prosaic, than any conclusions one might arrive at debating the history of and intention behind K&R's syntactic choices.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot hotspot-dev@openjdk.org integrated Pull request has been integrated
3 participants