JDK-8278309: [windows] use of uninitialized OSThread::_state #6734

tstuefe · 2021-12-07T06:10:20Z

May I have reviews for this trivial fix.

On Windows, we use OSThread::_state in os::create_thread before it has been initialized. This causes an assert to fire in Thread::is_JavaThread_protected (assert(target->is_handshake_safe_for(current_thread))

This only happens if the following is true:

We log os=info level, thereby firing the "Thread started.." log output the parent thread of a newly started child thread writes. Since JDK-8268773, we also print the thread name. Thread::name() uses Thread::is_JavaThread_protected, but on Windows, the thread state has not been set yet.
This is an assert, so only debug, but in debug newly malloced memory is poisoned with "F1F1F1F1...", which hides the error since Thread::is_JavaThread_protected compares the thread state like this:

  if (target->osthread() == NULL || target->osthread()->get_state() <= INITIALIZED) {
    return true;
  }

and the compiler interprets the "F1F1F1F1" as a negative large value. Changing the init pattern to 0x01, or adding an explicit cast to unsigned, causes the assert to fire as soon as logging is switched on.

Musings:

I wondered whether we should change the thread state comparison to unsigned like this:

  if (target->osthread() == NULL || (unsigned)target->osthread()->get_state() <= INITIALIZED) {

which would have shown the error right away after JDK-8268773. This is matter of taste though since one could say that at this point we expect the enum to be filled correctly with one of its values, and guarding against uninitialized memory should belong somewhere else, maybe in a debug-only verify function.

--

Just my personal opinion, but OSThread could do with a bit of cleanup. E.g. using an initializer list to init its values, and possibly doing the per-platform-factoring out in a different way. That include-file-in-the-middle-of-class composition technique is terrible. It confuses IDEs and makes analyzing the code difficult, and the code is not really difficult in what it does.

Tests: GHAs (twice, once with experimentally set init word to 1 to see that the patch works)

Progress

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

Issue

JDK-8278309: [windows] use of uninitialized OSThread::_state

Reviewers

David Holmes (@dholmes-ora - Reviewer) ⚠️ Review applies to f7e7249
Aleksey Shipilev (@shipilev - Reviewer) ⚠️ Review applies to e85638e

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6734

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

Using diff file

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

bridgekeeper · 2021-12-07T06:10:48Z

👋 Welcome back stuefe! 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 · 2021-12-07T06:12:39Z

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

mlbridge · 2021-12-07T09:07:32Z

Webrevs

dholmes-ora

Looks good. :)

Thanks,
David

openjdk · 2021-12-07T09:37:11Z

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

8278309: [windows] use of uninitialized OSThread::_state

Reviewed-by: dholmes, shade

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

5dcdee4: 8262341: Refine identical code in AddI/LNode.
b334d96: 8276964: Better indicate a snippet that could not be processed
30f0c64: 8277992: Add fast jdk_svc subtests to jdk:tier3
5266e7d: 8278379: Zero VM is broken due to UseRTMForStackLocks was not declared after JDK-8276901
e7db581: 8277168: AArch64: Enable arraycopy partial inlining with SVE
fb6d611: 8278276: G1: Refine naming of G1GCParPhaseTimesTracker::_must_record
d7ad546: 8276422: Add command-line option to disable finalization
ec7cb6d: 8276447: Deprecate finalization-related methods for removal
3c2951f: 8275771: JDK source code contains redundant boolean operations in jdk.compiler and langtools
3d61372: 8278363: Create extented container test groups
... and 29 more: https://git.openjdk.java.net/jdk/compare/5045eb538b3afc6cf646642f1109473597b3004a...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.

tstuefe · 2021-12-07T09:49:24Z

Looks good. :)

Thanks, David

Thank you David!

shipilev

This looks fine as the limited fix.

But I do wonder if the initial state ALLOCATED should be stamped right in the OSThread::OSThread constructor. Also, I see other platforms, for example, Linux does:

  // set the correct thread state
  osthread->set_thread_type(thr_type);

  // Initial state is ALLOCATED but not INITIALIZED
  osthread->set_state(ALLOCATED);

Not sure how safe it is to add set_thread_type, but matching the comment for set_state is probably in order.

tstuefe · 2021-12-07T13:31:33Z

This looks fine as the limited fix.

But I do wonder if the initial state ALLOCATED should be stamped right in the OSThread::OSThread constructor.

Oh totally. This makes me itch. But I wanted a minimal patch to downport, and knowing me once I start touching OSThread I can't stop pulling threads. Ideally, I would like to get rid of OSThread altogether and merge it into Thread; there is no reason to have two physically separate structures like this.

Also, I see other platforms, for example, Linux does:
  // set the correct thread state
  osthread->set_thread_type(thr_type);

  // Initial state is ALLOCATED but not INITIALIZED
  osthread->set_state(ALLOCATED);
Not sure how safe it is to add set_thread_type, but matching the comment for set_state is probably in order.

Windows does not have a thread type. About the comment, sure, I can do that. Will do it before pushing.

Thanks, Thomas

dholmes-ora

The comment at line 783 could be tweaked to no longer say "Initially".

I think a simple follow up RFE could move ALLOCATED into the constructor as Aleksey suggested, without opening up the whole cleanup can of worms.

Thanks,
David

tstuefe · 2021-12-08T08:13:33Z

Okay, fixed the comment as David suggested. If no objections come forward, I'll push after breakfast.

tstuefe · 2021-12-08T09:17:50Z

/integrate

openjdk · 2021-12-08T09:19:11Z

Going to push as commit 54993b1.
Since your change was applied there have been 40 commits pushed to the master branch:

10e0318: 8278158: jwebserver should set request timeout
5dcdee4: 8262341: Refine identical code in AddI/LNode.
b334d96: 8276964: Better indicate a snippet that could not be processed
30f0c64: 8277992: Add fast jdk_svc subtests to jdk:tier3
5266e7d: 8278379: Zero VM is broken due to UseRTMForStackLocks was not declared after JDK-8276901
e7db581: 8277168: AArch64: Enable arraycopy partial inlining with SVE
fb6d611: 8278276: G1: Refine naming of G1GCParPhaseTimesTracker::_must_record
d7ad546: 8276422: Add command-line option to disable finalization
ec7cb6d: 8276447: Deprecate finalization-related methods for removal
3c2951f: 8275771: JDK source code contains redundant boolean operations in jdk.compiler and langtools
... and 30 more: https://git.openjdk.java.net/jdk/compare/5045eb538b3afc6cf646642f1109473597b3004a...master

Your commit was automatically rebased without conflicts.

openjdk · 2021-12-08T09:19:31Z

@tstuefe Pushed as commit 54993b1.

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

openjdk bot added the hotspot hotspot-dev@openjdk.org label Dec 7, 2021

initialize osthread state on windows

e85638e

tstuefe force-pushed the osthread-uninitialized-member branch from b7058ef to e85638e Compare December 7, 2021 09:01

tstuefe marked this pull request as ready for review December 7, 2021 09:02

openjdk bot added the rfr Pull request is ready for review label Dec 7, 2021

dholmes-ora approved these changes Dec 7, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Dec 7, 2021

shipilev approved these changes Dec 7, 2021

View reviewed changes

add comment mirroring linux version

f7e7249

dholmes-ora approved these changes Dec 8, 2021

View reviewed changes

Feedback David

3941822

openjdk bot closed this Dec 8, 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 Dec 8, 2021

JDK-8278309: [windows] use of uninitialized OSThread::_state #6734

JDK-8278309: [windows] use of uninitialized OSThread::_state #6734

tstuefe commented Dec 7, 2021 •

edited by openjdk bot

bridgekeeper bot commented Dec 7, 2021

openjdk bot commented Dec 7, 2021

mlbridge bot commented Dec 7, 2021 •

edited

dholmes-ora left a comment

openjdk bot commented Dec 7, 2021 •

edited

tstuefe commented Dec 7, 2021

shipilev left a comment •

edited

tstuefe commented Dec 7, 2021

dholmes-ora left a comment

tstuefe commented Dec 8, 2021 •

edited

tstuefe commented Dec 8, 2021

openjdk bot commented Dec 8, 2021

openjdk bot commented Dec 8, 2021

JDK-8278309: [windows] use of uninitialized OSThread::_state #6734

JDK-8278309: [windows] use of uninitialized OSThread::_state #6734

Conversation

tstuefe commented Dec 7, 2021 • edited by openjdk bot

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Dec 7, 2021

openjdk bot commented Dec 7, 2021

mlbridge bot commented Dec 7, 2021 • edited

Webrevs

dholmes-ora left a comment

Choose a reason for hiding this comment

openjdk bot commented Dec 7, 2021 • edited

tstuefe commented Dec 7, 2021

shipilev left a comment • edited

Choose a reason for hiding this comment

tstuefe commented Dec 7, 2021

dholmes-ora left a comment

Choose a reason for hiding this comment

tstuefe commented Dec 8, 2021 • edited

tstuefe commented Dec 8, 2021

openjdk bot commented Dec 8, 2021

openjdk bot commented Dec 8, 2021

tstuefe commented Dec 7, 2021 •

edited by openjdk bot

mlbridge bot commented Dec 7, 2021 •

edited

openjdk bot commented Dec 7, 2021 •

edited

shipilev left a comment •

edited

tstuefe commented Dec 8, 2021 •

edited