Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8309633 | na | Daniel Daugherty | P4 | Closed | Not an Issue |
The loop for deleting ObjectMonitor is slow because of the transition to blocked for each iteration.
If we release oopStorage when deflating we can do this entire loop while blocked instead, which will be much faster.
Since we only need to free some c-heap.
From similar situations the differences can be up to 10x, mainly due to compiler may use much more aggressive optimizations and much better predictions (the list is random access).
In rare situations when we have a list with 10 k OMs, using 10 usec per item instead of 100 usec can mean we will not "get behind".
E.g. we then could do:
> size_t deleted_count = 0;
> ThreadBlockInVM tbivm(self);
> for (ObjectMonitor* monitor: delete_list) {
> delete monitor;
> deleted_count++;
> }
> }
If we release oopStorage when deflating we can do this entire loop while blocked instead, which will be much faster.
Since we only need to free some c-heap.
From similar situations the differences can be up to 10x, mainly due to compiler may use much more aggressive optimizations and much better predictions (the list is random access).
In rare situations when we have a list with 10 k OMs, using 10 usec per item instead of 100 usec can mean we will not "get behind".
E.g. we then could do:
> size_t deleted_count = 0;
> ThreadBlockInVM tbivm(self);
> for (ObjectMonitor* monitor: delete_list) {
> delete monitor;
> deleted_count++;
> }
> }
- backported by
-
JDK-8309633 releasing oopStorage when deflating allows for faster deleting
-
- Closed
-
- relates to
-
JDK-8309599 WeakHandle and OopHandle release should clear obj pointer
-
- Resolved
-
-
JDK-8319137 release _object in ObjectMonitor dtor to avoid races
-
- Closed
-
-
JDK-8253064 monitor list simplifications and getting rid of TSM
-
- Resolved
-
(1 links to)