JDK-6498391 : Remove all dead code related to the legacy vm_suspend/vm_resume API's
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-11-29
  • Updated: 2012-10-08
  • Resolved: 2007-01-17
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.
JDK 6 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
Related Reports
Relates :  
Description
The legacy vm_suspend/vm_resume API used to be used for a number of purposes in the VM, including safepoints and profiling. This usage has been deprecated over time and as of Java 6 (at least) there remains only one usage of this API: on linux, if the flat-profiler is profiling the VMThread then get_thread_pc is called and that uses vm_suspend.

Despite barely being used there is code related to vm_suspend/vm_resume scattered throughout the VM. Getting rid of this dead code will make the codebase easier to understand and maintain, might even improve performance in some places, and enables future simplification of other "entangled" code pertaining to the use of the SR_lock (which will end up being used only for the java-suspend mechanism).

The linux suspend/resume mechanism based on signals will be kept for use by the flat-profiler, and will be fixed, as presently the signal handler assumes it is called on a JavaThread when it never is. If you use "-Xprof -XX:+ProfileVM" on a linux fastdebug build you will get an assertion failure in the handler. Other unnecessary code in the linux suspend/resume code pertains to a mutex acquisition problem which has not existed for some time. In fact the use of the safe_mutex_lock/safe_cond_wait wrappers can be removed.

Comments
EVALUATION See description
29-11-2006