Re: How does the jsr 133 enforce the Java memory model

2016-07-18 Thread Aleksey Shipilev
Actually, in the context of advanced mental models, this might be a better follow-up reading: https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/ -Aleksey On Mon, Jul 18, 2016 at 11:55 PM, Martin Thompson wrote: > This is a good starting point to improve your understanding. > > https:

Re: Single writer counter: how expensive is a volatile read?

2016-10-29 Thread Aleksey Shipilev
On 10/29/2016 10:13 AM, Peter Veentjer wrote: > So you get something like this: > > public class Counter { > > private final AtomicLong c = new AtomicLong(); > > public void inc(){ > long newValue = c.get()+1; > c.lazySet(newValue); > } > > public long get(){ >

Re: Single writer counter: how expensive is a volatile read?

2016-10-30 Thread Aleksey Shipilev
On 10/30/2016 05:55 AM, Peter Veentjer wrote: > Let me clarify. > The discussion is around removing the volatile read in the inc method. Ah, sorry I misinterpreted the question. It usually goes the other way: the reads vastly outnumber the writes. Well, since the writer is single-threaded, there

Re: Single writer counter: how expensive is a volatile read?

2016-10-30 Thread Aleksey Shipilev
On 10/29/2016 10:31 PM, Vitaly Davidovich wrote: > There's one thing I still can't get someone at Oracle to clarify, which > is whether getOpaque ensures atomicity of the read. I believe it would, > but I don't think it's been explicitly stated thus far. Like std::atomic(..., mem_ord_relaxed), Va

Re: TLS(thread-local storage) on Java

2016-11-21 Thread Aleksey Shipilev
Hi, On 11/21/2016 07:58 PM, Sergey Melnikov wrote: > On Linux (I'm not sure about windows, but I think windows does it the > same way), kernel maps thread-local segment for current thread via FS > segment register. So, in C/C++ it's possible to get value from TLS > with only 1 (!) instruction: >

Re: TLS(thread-local storage) on Java

2016-11-22 Thread Aleksey Shipilev
On 11/21/2016 11:44 PM, Sergey Melnikov wrote: > Let's start from something like this: > > class Tls { > static class TlsKey { >private int key; > } > > public static Object getTlsObject(TlsKey k); > public static void setTls(TlsKey k, Object obj); > >

Re: Operation Reordering

2017-01-17 Thread Aleksey Shipilev
On 01/17/2017 12:55 PM, Vitaly Davidovich wrote: > Atomicity of values isn't something I'd assume happens automatically. Word > tearing isn't observable from single threaded code. On 01/17/2017 09:17 PM, Michael Barker wrote: > That was my understanding too. Normal load/stores on 32 bit JVMs wou

Re: Operation Reordering

2017-01-17 Thread Aleksey Shipilev
(triggered again) On 01/18/2017 12:33 AM, Sergey Melnikov wrote: > mov (%rax), %rbx > cmp %rbx, %rdx > jxx Lxxx > > But if you schedule them this way > > mov (%rax), %rbx > cmp %rbx, %rdx > ... few instructions > jxx Lxxx ...doesn't this give up on macro-fusion, and effectively sets up for a be

Re: Futex flood

2017-01-23 Thread Aleksey Shipilev
On 01/23/2017 05:42 AM, Дмитрий Пеньков wrote: > Hello everyone. I have following situation: multiple HotSpot JVMs with > multiple > GCs' (ParallelGC) threads on multiple CPUs. I've already seen recommendations > to > have min 2 cores per JVM, but in my case it's 80 CPU's and about 200 JVMs. > A

Re: HotSpot code cache and instruction prefetching

2017-02-03 Thread Aleksey Shipilev
On 02/03/2017 10:26 AM, Chris Newland wrote: > Do you think the HotSpot designers took this into account but found > empirically > that the simple algorithm is adequate (cost complexity outweighs gains and > hotimp > methods are generally JIT-compiled together). Let's ask another question: do yo

Re: Concurrency question.

2017-03-03 Thread Aleksey Shipilev
On 03/03/2017 10:51 AM, Grzegorz Gierlach wrote: > It passes on x86 however for some reason I'm not 100% sure it is a correct > implementation. Is there a better way of doing it? The discussion about "correct", "way of doing it" is irrelevant if you don't describe what is your intent with this tes

Re: Mystery: Why does the JVM show more latency for the same block of code after a busy spin pause?

2017-04-29 Thread Aleksey Shipilev
On 04/29/2017 04:56 PM, J Crawford wrote: > The mystery boils down to: > > "/The exact same block of code becomes slower after a busy spin pause./" > > I posted a short source code that *unequivocally* proves and demonstrates the > problem: > http://stackoverflow.com/questions/43696948/why-

Re: Mystery: Why does the JVM show more latency for the same block of code after a busy spin pause?

2017-04-29 Thread Aleksey Shipilev
On 04/29/2017 06:56 PM, Aleksey Shipilev wrote: > On 04/29/2017 04:56 PM, J Crawford wrote: >> The mystery boils down to: >> >> "/The exact same block of code becomes slower after a busy spin pause./" >> >> I posted a short source code that

Re: Mystery: Why does the JVM show more latency for the same block of code after a busy spin pause?

2017-04-29 Thread Aleksey Shipilev
On 04/29/2017 07:12 PM, Aleksey Shipilev wrote: > On 04/29/2017 06:56 PM, Aleksey Shipilev wrote: >> On 04/29/2017 04:56 PM, J Crawford wrote: >>> The mystery boils down to: >>> >>> "/The exact same block of code becomes slower after a busy spin paus

Re: failing to understand the issues with transparent huge paging

2017-08-09 Thread Aleksey Shipilev
On 08/08/2017 06:44 PM, Gil Tene wrote: > On Monday, August 7, 2017 at 11:50:27 AM UTC-7, Alen Vrečko wrote: > Saw this a while back. > > https://shipilev.net/jvm-anatomy-park/2-transparent-huge-pages/ > > > Basical

Re: allocation memory in Java

2017-11-18 Thread Aleksey Shipilev
On 11/17/2017 11:46 PM, John Hening wrote: > For my eye, common objects in Java, like  > > newString(); > > is a CHeapObj. I looked at an implementation of new operator in that class > and it looks like: In related news, there is javaClasses.cpp, and therefore Java class library is written in

Re: allocation memory in Java

2017-11-20 Thread Aleksey Shipilev
On 11/18/2017 01:45 PM, John Hening wrote: > Thanks for your replies :) > > @Aleksey, how to get that? > > |-17.12%0.00%org.openjdk.Allperf-31615.map-0x7faaa3b2d125-16.59%OptoRuntime::new_instance_C > -11.49%InstanceKlass::allocate_instance > 2.33%BlahBlahBlahCollectedHeap::mem_allocate

Re: JVM detection of thread at safepoint

2017-12-05 Thread Aleksey Shipilev
On 12/05/2017 09:26 AM, Mark Price wrote: > I'm investigating some long time-to-safepoint pauses in oracle/openjdk. The > application in question > is also suffering from some fairly nasty I/O problems where latency-sensitive > threads are being > descheduled in uninterruptible sleep state due to

Re: Is there a way to print Escape Analysis?

2018-01-25 Thread Aleksey Shipilev
On 01/25/2018 03:44 AM, 'Carl Mastrangelo' via mechanical-sympathy wrote: > Consider the following code: > > public class Test { >   static volatile Integer discard; >   public static void main(String [] args) throws InterruptedException { >     printMemory(); >     System.gc(); >     printMemory(

Re: JITed very simple method.

2018-02-04 Thread Aleksey Shipilev
On 02/04/2018 12:31 AM, John Hening wrote: > | > publicstaticintdontOptimize; > > > publicstaticintsimple(){ >  returndontOptimize; > } > | > > And JITed version of that: >   0x7fdc75112aa0:mov    %eax,-0x14000(%rsp) >   0x7fdc75112aa7:push   %rbp >   0x7fdc75112aa8:sub   $0x30,%rsp

Re: JITed very simple method.

2018-02-06 Thread Aleksey Shipilev
On 02/05/2018 09:58 PM, John Hening wrote: > 1. Why do you find it is a bug in tierred compilation machinery? It is not on > my eye.  The > compilation level is: C2, level 4 Wait a minute, where exactly does it say "C2, level 4" for you? I am saying the disassembly you have provided in the origi

Re: Nanotrusting the Nanotime and amortization.

2018-04-25 Thread Aleksey Shipilev
On 04/24/2018 10:44 PM, John Hening wrote: > I'm reading the great article from > https://shipilev.net/blog/2014/nanotrusting-nanotime/ (thanks > Aleksey! :)) and I am not sure whether I understand correctly that. > > Firstly, it is compared performance of plain and volatile writes: > > Benchmar

Re: JMM- conservative and formal point of view.

2018-05-16 Thread Aleksey Shipilev
On 05/16/2018 07:33 PM, John Hening wrote: > Subject: JMM- conservative and formal point of view. There is no "conservative" JMM point of view. There is JSR 133 Cookbook for Compiler Writers that describes the conservative implementation, but it is not the JMM itself. Reductio ad absurdum: suppo

Re: JMM- conservative and formal point of view.

2018-05-16 Thread Aleksey Shipilev
On 05/16/2018 09:19 PM, John Hening wrote: > By the way, in your transcription you said: > | >     inta; > >     volatilebooleanready =false; > >     voidactor(IntResult1r){ >         while(!ready){}; >         r.r1 =a; >     } > >     voidobserver(){ >         a =41; >         a =42; >        

Re: Release fence pollution in constructors and builders

2019-07-17 Thread Aleksey Shipilev
On 7/17/19 9:06 AM, Andriy Plokhotnyuk wrote: > 1) Using of release (and sometime store-store) fences in all constructors in > GraalVM: > https://github.com/oracle/graal/blob/e9dbc9d6d3080daf22dec38ce8c234417e1a8e3c/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacemen

Re: Confusion regarding 'mark-sweep-compact' naming

2019-08-06 Thread Aleksey Shipilev
On 8/6/19 7:38 AM, Peter Veentjer wrote: > There is still some confusion on my side. This time it is regarding the > algorithmic complexity of > mark-sweep-compact. > > The complexity of the mark phase is linear to the live set. > The complexity of the sweep phase is linear to the heap size. > Th

Re: Confusion regarding 'mark-sweep-compact' naming

2019-08-14 Thread Aleksey Shipilev
On 8/14/19 11:30 AM, Gil Tene wrote: > For an easy to follow code example of Mark, Sweep, and Compact, look at the > (ahem...) psMarkSweep.c > code for the compacting OpenJDK ParallelGC oldgen implementation, which does > 4 separate passes ( > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/7

Re: Confusion regarding 'mark-sweep-compact' naming

2019-08-15 Thread Aleksey Shipilev
On 8/14/19 9:21 PM, Gil Tene wrote: > The fact that they visit and parse dead objects in order to identify > recycle-able memory is what makes them > sweepers. Other techniques that don't visit dead objects do not perform a > sweep. I am trying to understand what is your central argument here. T

Re: Confusion regarding 'mark-sweep-compact' naming

2019-08-16 Thread Aleksey Shipilev
time, but we have to be careful to separate what is the "agreed on" definition, and what is whatever definition we want to be the emergent one. > On Thursday, August 15, 2019 at 1:42:23 AM UTC-7, Aleksey Shipilev wrote: > I am trying to understand what is your central argument