RFR (M): 8160897: Concurrent mark mark stack memory allocation leaks memory
Thomas Schatzl
thomas.schatzl at oracle.com
Wed Jul 13 08:39:32 UTC 2016
Hi all,
can I have reviews for the following bugfix that makes global mark
stack memory management a little bit more sane:
- fixed a typo in some comment which (imho) reversed its meaning
- during resize of the mark stack,
- g1 does not unreserve that memory, it only tries and fails to
uncommit the memory (calling the wrong method).
- g1 does not assign the new memory the "mtGC" tag.
- if g1 fails reserving that new memory, we exit the VM. This is in
contrast to the original idea of just trying to continue with the
existing mark stack.
- during initial allocation of the mark stack, we issue a warning and
exit the constructor right away, leaving the class half-uninitialized.
This has been changed to a vm_exit_at_initialization() error.
- removed code duplication
- fixed indices/capacity types from int to size_t to avoid casting
around (subsuming JDK-8079081). I do not think it makes sense to mostly
rewrite G1CMMarkStack and then still inappropriately use ints.
- tried to fix up log messages
The change does not address:
- the (weird) policy when to actually increase the mark stack (is JDK-
8065402).
- recreate mappings during expansion, but could reserve all space up-
front and (un-commit) as necessary (is JDK-8151996)
- mark stack contention (follow-up JDK-8159422)
Webrev:
http://cr.openjdk.java.net/~tschatzl/8160897/webrev/
Testing:
vm.gc, jprt, local testing of resizing mechanism
Thanks,
Thomas
More information about the hotspot-gc-dev
mailing list