| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8082568 | emb-9 | Max Ockner | P4 | Resolved | Fixed | team |
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).
- backported by
-
JDK-8082568 mutexLocker.cpp _mutex_array[] initialization broken with safepoint check change
-
- Resolved
-
- duplicates
-
JDK-8072406 _mutex_array not initialized properly
-
- Closed
-
- relates to
-
JDK-8047290 Make Mutex::_no_safepoint_check_flag locks verify that this lock never checks for safepoint
-
- Resolved
-