JDK-8009062 : poor performance of JNI AttachCurrentThread after fix for 7017193
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: hs24
- Priority: P2
- Status: Closed
- Resolution: Fixed
- OS: linux
- CPU: generic
- Submitted: 2013-02-26
- Updated: 2014-01-14
- Resolved: 2013-08-29
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.
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.
| JDK 8 | Other |
|---|---|
8Fixed  |
hs25Fixed |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
-------- Original Message -------- Date: Tue, 26 Feb 2013 17:58:45 +0000 From: Andrew Haley <aph@redhat.com> get_stack_bounds() was rewritten because of a small memory leak. Instead of simply free()ing the memory to prevent the leak, it was rewritten to use a byte-by-byte loop around read() : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-February/001864.html Unfortunately, the performance impact of this change is tragic. As you can imagine, tens of thousands of system calls are made whenever get_stack_bounds() is called. Before rewrite: typically 100 microseconds After rewrite: typically 1500 microseconds
Comments
|