JDK-8214428 : Fix for JDK-8212207 was incorrect
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-11-28
  • Updated: 2019-05-02
  • Resolved: 2018-12-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8214097 - Rework thread initialization and teardown logic
Relates :  
JDK-8212207 - runtime/InternalApi/ThreadCpuTimesDeadlock.java crashes with SEGV in pthread_getcpuclockid+0x0
Relates :  
JDK-8214097 - Rework thread initialization and teardown logic
Description
JDK-8212207 skipped NJT's until they had their stack size set, but the pthread_id may be set _after_ that:

Thomas Stuefe writes:
On Linux, pthread id is set in the parent thread, after pthread_create returns. Only the kernel thread id is set by the child (I find this duality confusing). thread_cpu_time uses pthread_id. So, on Linux, it may or may not be set before the thread stack boundaries are initialized, depending on whether the native entry function ran before the parent thread continued.

---

So it is still possible to see a zero pthread_t for the new thread..
Comments
The fix for JDK-8214097 will remove the fix from 8212207 as it is no longer needed.
18-12-2018
I may just fix this as part of JDK-8214097 by only adding to the NJT list once the thread has executed its own initialization logic beyond the handshake with the creating thread.
28-11-2018