P4 | Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2177110 | 7 | Igor Veresov | P3 | Closed | Fixed | b27 |
| JDK-2174922 | 6u14 | Igor Veresov | P3 | Resolved | Fixed | b01 |
Premature GC will happen after a call to MutableNUMASpace::ensure_parsibility().
Also on a machine with specific configuration an invalid lgrp selection can occur. For example of arches.sfbay there are two leaf locality group associated with each CPU. But only one of them has memory. The resulting lgrp graph is as follows:
1 (CM) <- 0 (CM) -> 2 (C)
where attributes in parenthesis are C - CPU, M - memory.
With such a configuration Solaris always selects group 0 as a home group for all LWPs.
This situation was not handled correctly and a random leaf group was selected.
Combined with incorrect tops adjustment random selection can select a chunk with no free space. Should such an event happen during VM initialization a crash occurs.
Also on a machine with specific configuration an invalid lgrp selection can occur. For example of arches.sfbay there are two leaf locality group associated with each CPU. But only one of them has memory. The resulting lgrp graph is as follows:
1 (CM) <- 0 (CM) -> 2 (C)
where attributes in parenthesis are C - CPU, M - memory.
With such a configuration Solaris always selects group 0 as a home group for all LWPs.
This situation was not handled correctly and a random leaf group was selected.
Combined with incorrect tops adjustment random selection can select a chunk with no free space. Should such an event happen during VM initialization a crash occurs.
- backported by
-
JDK-2174922 Premature GC and invalid lgrp selection with NUMA-aware allocator.
-
- Resolved
-
-
-
- Closed
-