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