[PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup
hboehm at google.com
Fri Feb 2 00:03:31 UTC 2018
On Thu, Feb 1, 2018 at 2:50 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi Ben,
> I don’t think you require the fence in all the cases you have currently
placed it e.g. here for example
> $memtype$ y = $toBits$(x);
> UNSAFE.put$Memtype$Unaligned(null, a, y, bigEndian);
> + Reference.reachabilityFence(this);
> return this;
> since “this” is being returned it will be kept live during the unsafe
I don't see how that's guaranteed by the JLS, specifically 12.6.2. What if
this function is inlined into the caller, and the caller drops the result?
I would still greatly prefer to see an added mechanism (possibly along the
that associates the reachability requirements with fields or classes,
rather than putting a reachabilityFence() in every method accessing a
field. I'm sure there are cases where reachabilityFence() is the preferred
mechanism. But for the code I've looked at recently, I haven't actually
found one yet. I don't think it is a good mechanism here, either.
> Would you mind providing a JMH benchmark and results for the performance
with and without the fence for say a put and/or a get. I would like to
understand the performance impact on HotSpot, this is one reason why we
have yet to add such fences as it will likely impact performance.
> At the moment we are relying on the method not being inlined, which is an
expedient technique to make it functional and keep a reference alive but
not necessarily optimal for usages in DBB.
But that should be fixable, right? It shouldn't generate any code beyond
potentially preventing register or stack slot reuse; the required effect of
reachabilityFence (in a conventional implementation) is to ensure that the
argument is considered live at any preceding GC points.
> For more details see:
> https://bugs.openjdk.java.net/browse/JDK-8169605 <
> https://bugs.openjdk.java.net/browse/JDK-8149610 <
More information about the core-libs-dev