Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Hi Peter, Thanks, well spotted. I adjusted to: try { return finalized.get(); } finally { Reference.reachabilityFence(o); } I also created this issue: https://bugs.openjdk.java.net/browse/JDK-8199462 http://cr.openjdk.java.net/~psandoz/jdk/buffer-reachability-fence/webrev/

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Hi, On 03/02/18 18:15, Paul Sandoz wrote: Thanks! Paul. On Mar 2, 2018, at 9:11 AM, Vladimir Ivanov wrote: On 3/2/18 8:01 PM, Paul Sandoz wrote: Here’s an update Ben and I tweaked: http://cr.openjdk.java.net/~psandoz/jdk/buffer-reachability-fence/webrev/index.html I think this looks

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Thanks! Paul. > On Mar 2, 2018, at 9:11 AM, Vladimir Ivanov > wrote: > > > > On 3/2/18 8:01 PM, Paul Sandoz wrote: >> Here’s an update Ben and I tweaked: >> >> http://cr.openjdk.java.net/~psandoz/jdk/buffer-reachability-fence/webrev/index.html >> I think this looks good but would still lik

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

On 3/2/18 8:01 PM, Paul Sandoz wrote: Here’s an update Ben and I tweaked: http://cr.openjdk.java.net/~psandoz/jdk/buffer-reachability-fence/webrev/index.html I think this looks good but would still like to double check with Vladimir that the @ForceInline is not problematic. I confirm t

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Here’s an update Ben and I tweaked: http://cr.openjdk.java.net/~psandoz/jdk/buffer-reachability-fence/webrev/index.html I think this looks good but would still like to double check with Vladimir that the @ForceInline is not problematic. Paul. > On Feb 26, 2018, at 6:50 PM, Paul Sandoz wrot

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

_buffer_put 1000 thrpt 200 > 1629413.444 ± 24163.399 ops/s -1.012% > ByteBufferBenchmark.benchmark_byte_buffer_put 1 thrpt 200 > 182250.811 ± 2028.461 ops/s -0.675% > > - Build With Reference.reachabilityFences Added And DontInline Removed - > > Benchmark

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Hi Ben, Much better :-) thanks for doing this. Before preceding with replacing @DontInline with @ForceInline i would like to appeal to Vladimir to confirm this is ok. If you send me an attached patch directly in email i can upload it as a webrev for you, it should be easier to review. (When yo

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

rk_byte_buffer_put 1 thrpt 200 183463.292 ± 2056.016 ops/s -0.014% Regards, Ben From: Paul Sandoz To: Ben Walsh Cc: core-libs-dev Date: 08/02/2018 16:54 Subject:Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup Hi Ben, Thanks. I ant

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Hi Ben, Thanks. I anticipated a performance hit but not necessarily a 10x. Without looking at the generated code of the benchmark method it is hard to be sure [*], but i believe the fence is interfering with loop unrolling and/or vectorization, the comparative differences between byte and int m

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

- Regards, Ben Walsh From: Ben Walsh/UK/IBM To: Paul Sandoz Cc: core-libs-dev Date: 05/02/2018 16:47 Subject:Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Vladimir, just to be sure I presume your analysis applies to both C1 and C2? what about compilers such as Graal? I only looked at C1 & C2, but I'm sure it applies to Graal as well: GC interaction mechanism is the same for all JIT-compilers in HotSpot. Best regards, Vladimir Ivanov

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

> On Feb 7, 2018, at 7:22 AM, Vladimir Ivanov > wrote: > > Peter, > >>> Objects.requireNonNull() shows zero overhead here. >>> >>> I guess the main question is whether Objects.requireNonNull(this) behavior >>> in the former test is a result of chance and current Hotspot behavior or is >>>

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Peter, Objects.requireNonNull() shows zero overhead here. I guess the main question is whether Objects.requireNonNull(this) behavior in the former test is a result of chance and current Hotspot behavior or is it somehow guaranteed by the spec. I haven't looked into what actually happens i

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Objects.requireNonNull() shows zero overhead here. I guess the main question is whether Objects.requireNonNull(this) behavior in the former test is a result of chance and current Hotspot behavior or is it somehow guaranteed by the spec. I haven't looked into what actually happens in JIT-com

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Hi, I checked the behavior of Objects.requireNonNull(this) at appropriate place instead of Reference.reachabilityFence(this) and it does seem to work. For example in the following test (see method m()): import java.util.Objects; import java.util.concurrent.atomic.AtomicLong; public class Re

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Hi Ben, Thanks for looking into this. > On Feb 5, 2018, at 8:52 AM, Ben Walsh wrote: > > Running with the following test under the JMH benchmark framework (never > used this before, so please do point out any issues with the test) … > Your benchmark looks good, i would return the byte buffe

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

s-dev Date: 01/02/2018 22:50 Subject: Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup 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$

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Hi, I have one question, maybe stupid. I'm wondering about one situation. Suppose you have this Java code: void m() {     // code before...     Objects.requireNonNull(this); } Of course, the non-null check will never throw NPE. The check will most likely even be optimized away by JIT. But i

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

> On Feb 1, 2018, at 4:03 PM, Hans Boehm wrote: > > > On Thu, Feb 1, 2018 at 2:50 PM, Paul Sandoz > 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 > > > > $memty

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

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

[PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

This contribution forms a partial solution to the problem detailed here - http://thevirtualmachinist.blogspot.ca/2011/07/subtle-issue-of-reachability.html . In this context, this contribution provides "markers" such that a suitably "aware" compiler can reduce the chances of such a problem occurr