JDK-8072128 : mutexLocker.cpp _mutex_array[] initialization broken with safepoint check change
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 9
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2015-02-02
- Updated: 2015-06-03
- Resolved: 2015-03-20
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 9 |
|---|
9 b64Fixed  |
Related Reports
|
Duplicate :
|
|
|
Relates :
|
Description
On 2/2/15, 11:54 AM, Claes Redestad wrote:
> Hi,
>
> I know this has been pushed, but I wonder if the removal of _num_mutex++ from
> the def macro in mutexLocker.cpp was really intentional?
>
> It seems to me this means _mutex_array won't initialize properly in the current
> code, breaking print_owned_locks_on_error (always prints None). Bug?
>
> /Claes
170 #define def(var, type, pri, vm_block, safepoint_check_allowed ) { \
171 var = new type(Mutex::pri, #var, vm_block, safepoint_check_allowed); \
172 assert(_num_mutex < MAX_NUM_MUTEX, "increase MAX_NUM_MUTEX"); \
173 _mutex_array[_num_mutex] = var; \
174 }
Should be _num_mutex++ so that there is an array of mutexes (not just one).