From 420523349f24f1291cd5de45ac0c5f580c4a60a7 Mon Sep 17 00:00:00 2001 From: Filip Jeremic Date: Thu, 29 Nov 2018 13:10:56 -0500 Subject: [PATCH] Add comment regarding disabled CS wrtbar optimization The TODO is addressed by adding a comment describing why a particular optimization related to wrtbars is disabled under concurrent scavenge. Signed-off-by: Filip Jeremic --- compiler/optimizer/VPHandlers.cpp | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/compiler/optimizer/VPHandlers.cpp b/compiler/optimizer/VPHandlers.cpp index 59b25630e64..e0bcc25bfbc 100644 --- a/compiler/optimizer/VPHandlers.cpp +++ b/compiler/optimizer/VPHandlers.cpp @@ -2941,7 +2941,18 @@ TR::Node *constrainWrtBar(OMR::ValuePropagation *vp, TR::Node *node) if (TR::Compiler->om.shouldGenerateReadBarriersForFieldLoads()) { - // TODO (GuardedStorage): Why do we need this restriction? + // The optimization below targets the following type of code: + // + // X x = new X(); + // x.a = new A(); + // + // Most of the time both newly allocated objects would be in the nursery and there is no need for a generational + // barrier. However, in a rare case that a GC occurs in between the two allocations above the premise can be + // violated (by tenuring the first, but not the second object). The GC will compensate for the lack of the + // barrier by auto-remembering all objects that are tenured and directly stack referenced. + // + // This optimization is currently disabled when read barriers are required as it is currently unknown whether + // this optimization is safe under such a GC mode. doOpt = false; }