Skip to content

8265035: Remove unneeded exception check from refill_ic_stubs() #3436

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 2 commits into from
Closed

8265035: Remove unneeded exception check from refill_ic_stubs() #3436

wants to merge 2 commits into from

Conversation

pchilano
Copy link
Contributor

@pchilano pchilano commented Apr 12, 2021 •
edited by openjdk bot
Loading

Hi,

Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions.
The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set.

Thanks,
Patricio

Progress

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

Issue

  • JDK-8265035: Remove unneeded exception check from refill_ic_stubs()

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3436/head:pull/3436
$ git checkout pull/3436

Update a local copy of the PR:
$ git checkout pull/3436
$ git pull https://git.openjdk.java.net/jdk pull/3436/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3436

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3436.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Apr 12, 2021

👋 Welcome back pchilanomate! 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
Copy link

openjdk bot commented Apr 12, 2021

@pchilano The following label will be automatically applied to this pull request:

  • hotspot-compiler

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-compiler hotspot-compiler-dev@openjdk.org label Apr 12, 2021
@pchilano
Copy link
Contributor Author

/label add hotspot-runtime

@openjdk openjdk bot added the hotspot-runtime hotspot-runtime-dev@openjdk.org label Apr 12, 2021
@openjdk
Copy link

openjdk bot commented Apr 12, 2021

@pchilano
The hotspot-runtime label was successfully added.

@pchilano
Copy link
Contributor Author

/label remove hotspot-compiler

@openjdk openjdk bot removed the hotspot-compiler hotspot-compiler-dev@openjdk.org label Apr 12, 2021
@openjdk
Copy link

openjdk bot commented Apr 12, 2021

@pchilano
The hotspot-compiler label was successfully removed.

@pchilano pchilano marked this pull request as ready for review April 12, 2021 16:22
@openjdk openjdk bot added the rfr Pull request is ready for review label Apr 12, 2021
@mlbridge
Copy link

mlbridge bot commented Apr 12, 2021 •
edited
Loading

Webrevs

hseigel
hseigel approved these changes Apr 12, 2021
View reviewed changes
Copy link
Member

@hseigel hseigel left a comment

Choose a reason for hiding this comment

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

The changes look good. Were regression tests run?
Thanks, Harold

@openjdk
Copy link

openjdk bot commented Apr 12, 2021 •
edited
Loading

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

8265035: Remove unneeded exception check from refill_ic_stubs()

Reviewed-by: hseigel, dholmes

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

  • 008fc75: 8264224: Add macosx-aarch64 to Oracle build configurations
  • f4e6395: 8264190: Harden TLS interop tests
  • 18bec9c: 8265084: [BACKOUT] 8264954: unified handling for VectorMask object re-materialization during de-optimization
  • 9dd9625: 8263763: Synthetic constructor parameters of enum are not considered for annotation indices
  • 1ee80e0: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding
  • d84a7e5: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records
  • 714ae54: 8258788: incorrect response to change in window insets [lanai]
  • f479437: 8265082: test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java fails validate-source
  • 27f4b27: 8264623: Change to Xcode 12.4 for building on Macos at Oracle
  • 7c20d97: 8265052: Break circular include dependency in objArrayOop.inline.hpp
  • ... and 1 more: https://git.openjdk.java.net/jdk/compare/125184e96f577bbc031c3eba40b185b2b728b2c7...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 Apr 12, 2021
@pchilano
Copy link
Contributor Author

The changes look good. Were regression tests run?
Thanks, Harold
Thanks Harold! Yes, I run tiers 1-3 in mach5.

dholmes-ora
dholmes-ora approved these changes Apr 12, 2021
View reviewed changes
Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

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

Hi Patricio,

Changes look good.

Though I wonder whether we even need the EXCEPTION_MARK?

Thanks,
David

@pchilano
Copy link
Contributor Author

Hi David,

Thanks for looking at this.

Changes look good.

Though I wonder whether we even need the EXCEPTION_MARK?

I think it can be removed actually. The alternative could be to change it for assert(!HAS_PENDING_EXCEPTION, "there should be no pending exceptions") to only verify that there are no pending exceptions when entering refill_ic_stubs(). But I think that only makes sense if the following code can throw exceptions and you want to avoid overriding a possibly already pending one. So if you are okay too I can remove it.

Thanks,
Patricio

Thanks,
David

@mlbridge
Copy link

mlbridge bot commented Apr 13, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

On 13/04/2021 11:55 am, Patricio Chilano Mateo wrote:

On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

Hi,

Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions.
The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set.

You also need to manifest THREAD to use HAS_PENDING_EXCEPTION. I suspect
the EM was introduced purely to make THREAD available for the code
you've removed.

I have no concerns with removing the EM if you want to.

Thanks,
David

@pchilano
Copy link
Contributor Author

On 13/04/2021 11:55 am, Patricio Chilano Mateo wrote:

On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote:

Hi,
Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions.
The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set.

You also need to manifest THREAD to use HAS_PENDING_EXCEPTION. I suspect
the EM was introduced purely to make THREAD available for the code
you've removed.

I have no concerns with removing the EM if you want to.

Ok, I removed the EM.

Thanks!

Patricio

dholmes-ora
dholmes-ora approved these changes Apr 13, 2021
View reviewed changes
Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

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

LGTM!

Thanks,
David

@pchilano
Copy link
Contributor Author

Thanks @hseigel and @dholmes-ora for the reviews!

@pchilano
Copy link
Contributor Author

/integrate

@openjdk openjdk bot closed this Apr 13, 2021
@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 Apr 13, 2021
@openjdk
Copy link

openjdk bot commented Apr 13, 2021

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

  • fced0f0: 8265113: ProblemList gtest/GTestWrapper.java:os.release_multi_mappings on macosx-aarch64
  • 2aae29c: 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64
  • a84d886: 8265112: ProblemList some java/foreign tests on macosx-aarch64
  • 87e39cb: 8265110: ProblemList compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java on macosx-aarch64
  • 784f1c1: 8264200: java/nio/channels/DatagramChannel/SRTest.java fails intermittently
  • a4f644e: 8265064: Move clearing and setting of members into helpers in ReservedSpace
  • 7006070: 8265061: Simplify MethodHandleNatives::canBeCalledVirtual
  • 1935655: 8264957: Cleanup unused array Type::dual_type
  • 954b9a1: 8264795: IGV: Upgrade NetBeans platform
  • f2f7aa3: 8262291: Refactor reserve_memory_special_huge_tlbfs
  • ... and 11 more: https://git.openjdk.java.net/jdk/compare/125184e96f577bbc031c3eba40b185b2b728b2c7...master

Your commit was automatically rebased without conflicts.

Pushed as commit 943503e.

💡 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
Reviewers

@hseigel hseigel hseigel approved these changes

@dholmes-ora dholmes-ora dholmes-ora approved these changes

Assignees
No one assigned
Labels
hotspot-runtime hotspot-runtime-dev@openjdk.org integrated Pull request has been integrated
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@pchilano @hseigel @dholmes-ora