-
Bug
-
Resolution: Fixed
-
P4
-
11
-
b10
-
linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8200621 | 12 | Claes Redestad | P4 | Closed | Not an Issue |
On linux, we scan /proc/self/maps to be able to tell if the current thread is the "primordial" one.
However, when initializing the VM, most launchers spawn a new thread rather than initializing the VM on the primordial thread. If we can communicate this, or even better retrieve and communicate the tid of the primordial thread, we might just be able to avoid reading /proc/self/maps on startup.
Experimentally this saves ~0.7ms on my machine, which is about 1.5% of the total of the startup on a minimal image.
However, when initializing the VM, most launchers spawn a new thread rather than initializing the VM on the primordial thread. If we can communicate this, or even better retrieve and communicate the tid of the primordial thread, we might just be able to avoid reading /proc/self/maps on startup.
Experimentally this saves ~0.7ms on my machine, which is about 1.5% of the total of the startup on a minimal image.
- backported by
-
JDK-8200621 Avoid calculating primordial thread stack bounds on VM startup
- Closed
- relates to
-
JDK-8221639 [i386] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717
- Resolved