Re: Happens before between putting and getting from and to ConcurrentHashMap

[Roman Leventov]

On the other hand, CHM didn't guarantee volatile store semantics of put(),
it only guaranteed HB between get() and put() with the same key. However,
it's the same for java.util.concurrent's Queue implementations, such as
ConcurrentLinkedQueue: Javadoc doesn't say that queue.offer() and poll()
are synchronization actions.

On Mon, 19 Nov 2018 at 16:11, Francesco Nigro  wrote:

> It would matter if you add some logic around it:
>
> //put of a value in the map with just a lazySet/putOrdered etc etc
>
> If (anyConsumerIsSleeping()) {
>wakeUpConsumers();
> }
>
> If you won't have a full barrier the compile *could* reorder
> anyConsumerIsSleeping() ahead of the map.put, making possible to miss some
> consumer that is gone asleep :)
> The consumer example is more related to a queue case, but the idea is the
> same: you can't rely on any sequential consistent order on that operation
> (the volatile store), because without a volatile store that order doesn't
> exist.
>
> Il giorno lunedì 19 novembre 2018 14:04:15 UTC+1, Roman Leventov ha
> scritto:
>>
>> Does anybody understand what could go wrong if that CHM.Node.value
>> volatile write is relaxed to storeFence + normal write, and no fence at all
>> within the CHM.Node constructor (Hotspot JVM only)?
>>
>> On Mon, 19 Nov 2018, 10:28 Jean-Philippe BEMPEL > wrote:
>>
>>> Thanks Vladimir for your thoroughly explanation, I need to re read the
>>> Aleksey's JMM pragmatics 10 times more I guess 
>>>
>>> On Sun, Nov 18, 2018 at 7:35 PM Vladimir Sitnikov 
>>> wrote:
>>>
>>>> Jean-Philippe>is a write to value but no read of this va lue inside the
>>>> same thread, so the write is free to be reordered
>>>>
>>>> It ("reordering") does not really matter.
>>>>
>>>> For instance,
>>>>
>>>> 17.4.5. Happens-before Order> If the reordering produces results
>>>> consistent with a legal execution, it is not illegal.
>>>>
>>>> What matters is the set of possible "writes" that given "read" is
>>>> allowed to observe.
>>>>
>>>>
>>>> In this case, simple transitivity is enough to establish hb.
>>>> As Gil highlights, "negations" are a bit hard to deal with, and
>>>> Mr.Alexey converts the negations to a positive clauses:
>>>> https://shipilev.net/blog/2014/jmm-pragmatics/#_happens_before
>>>>
>>>> Shipilёv> Therefore, in the absence of races, we can only see the
>>>> latest write in HB.
>>>>
>>>> Note: we (as programmers) do not really care HOW the runtime and/or CPU
>>>> would make that possible. We have guarantees from JVM that "in the absence
>>>> of races, we can only see the latest write in HB".
>>>> CPU can reorder things and/or execute multiple instructions in
>>>> parallel. I don't really need to know the way it is implemented in order to
>>>> prove that "CHM is fine to share objects across threads".
>>>>
>>>> Just in case: there are two writes for w.value field.
>>>> "write1" is "the write of default value" which "synchronizes-with the
>>>> first action in every thread" (see 17.4.4.) + "If an action x
>>>> synchronizes-with a following action y, then we also have hb(x, y)." (see
>>>> 17.4.5)
>>>> "write2" is "w.value=42"
>>>>
>>>> "value=0" (write1) happens-before "w.value=42" (write2) by definition
>>>> (17.4.4+17.4.5)
>>>> w.value=42 happens-before map.put (program order implies happens-before)
>>>> read of u.value happens-before map.put (CHM guarantees that)
>>>>
>>>> In other words, "w.value=42" is the latest write in hb order for
>>>> u.value read, so u.value must observe 42.
>>>> JRE must ensure that the only possible outcome for the program in
>>>> question is 42.
>>>>
>>>> Vladimir
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "mechanical-sympathy" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to mechanical-sympathy+unsubscr...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "mechanical-sympathy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mechanical-sympathy+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Happens before between putting and getting from and to ConcurrentHashMap

[Roman Leventov]

Does anybody understand what could go wrong if that CHM.Node.value volatile
write is relaxed to storeFence + normal write, and no fence at all within
the CHM.Node constructor (Hotspot JVM only)?

On Mon, 19 Nov 2018, 10:28 Jean-Philippe BEMPEL  Thanks Vladimir for your thoroughly explanation, I need to re read the
> Aleksey's JMM pragmatics 10 times more I guess 
>
> On Sun, Nov 18, 2018 at 7:35 PM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
>> Jean-Philippe>is a write to value but no read of this va lue inside the
>> same thread, so the write is free to be reordered
>>
>> It ("reordering") does not really matter.
>>
>> For instance,
>>
>> 17.4.5. Happens-before Order> If the reordering produces results
>> consistent with a legal execution, it is not illegal.
>>
>> What matters is the set of possible "writes" that given "read" is allowed
>> to observe.
>>
>>
>> In this case, simple transitivity is enough to establish hb.
>> As Gil highlights, "negations" are a bit hard to deal with, and Mr.Alexey
>> converts the negations to a positive clauses:
>> https://shipilev.net/blog/2014/jmm-pragmatics/#_happens_before
>>
>> Shipilёv> Therefore, in the absence of races, we can only see the latest
>> write in HB.
>>
>> Note: we (as programmers) do not really care HOW the runtime and/or CPU
>> would make that possible. We have guarantees from JVM that "in the absence
>> of races, we can only see the latest write in HB".
>> CPU can reorder things and/or execute multiple instructions in parallel.
>> I don't really need to know the way it is implemented in order to prove
>> that "CHM is fine to share objects across threads".
>>
>> Just in case: there are two writes for w.value field.
>> "write1" is "the write of default value" which "synchronizes-with the
>> first action in every thread" (see 17.4.4.) + "If an action x
>> synchronizes-with a following action y, then we also have hb(x, y)." (see
>> 17.4.5)
>> "write2" is "w.value=42"
>>
>> "value=0" (write1) happens-before "w.value=42" (write2) by definition
>> (17.4.4+17.4.5)
>> w.value=42 happens-before map.put (program order implies happens-before)
>> read of u.value happens-before map.put (CHM guarantees that)
>>
>> In other words, "w.value=42" is the latest write in hb order for u.value
>> read, so u.value must observe 42.
>> JRE must ensure that the only possible outcome for the program in
>> question is 42.
>>
>> Vladimir
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mechanical-sympathy+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Intra-process queue between Java and C++

[Roman Leventov]

Not much, I think. Anyway, as Martin pointed to OneToOneRingBuffer it's
irrelevant now.

On Fri, 30 Mar 2018, 19:17 Greg Young, <gregoryyou...@gmail.com> wrote:

> Will the 16 bytes save you time?
>
> On Fri, Mar 30, 2018 at 10:36 PM, Roman Leventov <leventov...@gmail.com>
> wrote:
>
>> Martin, thanks a lot!
>>
>> I thought about Aeron IPC, but as far as I understand it maps to the
>> queue model only when there is a single producer and a single consumer.
>> Also it felt a little too heavyweight for small fixed-sized messages.
>> Generally Aeron's Data frames have 32-byte headers. RingBuffers have only
>> 16-byte headers, and it looks like it could be harmlessly reduced down to 8
>> or even 0 for e. g. fixed format 32-byte messages.
>>
>> On 30 March 2018 at 13:00, Martin Thompson <mjpt...@gmail.com> wrote:
>>
>>> There are implementations of FIFO ring buffers for Java and C++ used in
>>> Aeron for doing exactly this.
>>>
>>>
>>> https://github.com/real-logic/aeron/tree/master/aeron-client/src/main/cpp/concurrent
>>>
>>>
>>> https://github.com/real-logic/agrona/tree/master/agrona/src/main/java/org/agrona/concurrent
>>>
>>> You could also use Aeron IPC.
>>>
>>> On Friday, 30 March 2018 09:55:23 UTC+1, Roman Leventov wrote:
>>>>
>>>> I think about the possibility of building an asynchronous application
>>>> with back pressure where some upstream operators are in Java and some
>>>> downstream ones are in C++. For this purpose, some queues would be needed
>>>> to pass the data between Java and C++ layers. It seems that porting
>>>> JCTools's bounded array queues to off-heap should be doable, but I couldn't
>>>> find existing prototypes or discussions of such thing so maybe I overlook
>>>> some inherent complications with this idea.
>>>>
>>>> Did anybody think about something like this or has implemented in
>>>> proprietary systems?
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "mechanical-sympathy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mechanical-sympathy+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mechanical-sympathy+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Studying for the Turing test
>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Intra-process queue between Java and C++

[Roman Leventov]

Right, 8 bytes, not 16, I've misread
https://github.com/real-logic/agrona/blob/master/agrona/src/main/java/org/agrona/concurrent/ringbuffer/RecordDescriptor.java.
Thanks for note.

On Fri, 30 Mar 2018, 19:16 Martin Thompson, <mjpt...@gmail.com> wrote:

> Aeron IPC is more functional than a plain queue but I get your point that
> it is not a drop in replacement.
>
> The ring buffers are typical queue based semantics and use an 8 byte
> header in Agrona and Aeron. 4 bytes for message length and 4 bytes for
> message type to give some flexibility. Fixed format messages can optimise
> well but have limited applicability.
>
> On Friday, 30 March 2018 16:36:09 UTC+1, Roman Leventov wrote:
>>
>> Martin, thanks a lot!
>>
>> I thought about Aeron IPC, but as far as I understand it maps to the
>> queue model only when there is a single producer and a single consumer.
>> Also it felt a little too heavyweight for small fixed-sized messages.
>> Generally Aeron's Data frames have 32-byte headers. RingBuffers have only
>> 16-byte headers, and it looks like it could be harmlessly reduced down to 8
>> or even 0 for e. g. fixed format 32-byte messages.
>>
>> There are implementations of FIFO ring buffers for Java and C++ used in
>>> Aeron for doing exactly this.
>>>
>>>
>>> https://github.com/real-logic/aeron/tree/master/aeron-client/src/main/cpp/concurrent
>>>
>>>
>>> https://github.com/real-logic/agrona/tree/master/agrona/src/main/java/org/agrona/concurrent
>>>
>>> You could also use Aeron IPC.
>>>
>>> On Friday, 30 March 2018 09:55:23 UTC+1, Roman Leventov wrote:
>>>>
>>>> I think about the possibility of building an asynchronous application
>>>> with back pressure where some upstream operators are in Java and some
>>>> downstream ones are in C++. For this purpose, some queues would be needed
>>>> to pass the data between Java and C++ layers. It seems that porting
>>>> JCTools's bounded array queues to off-heap should be doable, but I couldn't
>>>> find existing prototypes or discussions of such thing so maybe I overlook
>>>> some inherent complications with this idea.
>>>>
>>>> Did anybody think about something like this or has implemented in
>>>> proprietary systems?
>>>>
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Intra-process queue between Java and C++

[Roman Leventov]

Martin, thanks a lot!

I thought about Aeron IPC, but as far as I understand it maps to the queue
model only when there is a single producer and a single consumer. Also it
felt a little too heavyweight for small fixed-sized messages. Generally
Aeron's Data frames have 32-byte headers. RingBuffers have only 16-byte
headers, and it looks like it could be harmlessly reduced down to 8 or even
0 for e. g. fixed format 32-byte messages.

On 30 March 2018 at 13:00, Martin Thompson <mjpt...@gmail.com> wrote:

> There are implementations of FIFO ring buffers for Java and C++ used in
> Aeron for doing exactly this.
>
> https://github.com/real-logic/aeron/tree/master/aeron-
> client/src/main/cpp/concurrent
>
> https://github.com/real-logic/agrona/tree/master/agrona/src/
> main/java/org/agrona/concurrent
>
> You could also use Aeron IPC.
>
> On Friday, 30 March 2018 09:55:23 UTC+1, Roman Leventov wrote:
>>
>> I think about the possibility of building an asynchronous application
>> with back pressure where some upstream operators are in Java and some
>> downstream ones are in C++. For this purpose, some queues would be needed
>> to pass the data between Java and C++ layers. It seems that porting
>> JCTools's bounded array queues to off-heap should be doable, but I couldn't
>> find existing prototypes or discussions of such thing so maybe I overlook
>> some inherent complications with this idea.
>>
>> Did anybody think about something like this or has implemented in
>> proprietary systems?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Intra-process queue between Java and C++

[Roman Leventov]

I think about the possibility of building an asynchronous application with
back pressure where some upstream operators are in Java and some downstream
ones are in C++. For this purpose, some queues would be needed to pass the
data between Java and C++ layers. It seems that porting JCTools's bounded
array queues to off-heap should be doable, but I couldn't find existing
prototypes or discussions of such thing so maybe I overlook some inherent
complications with this idea.

Did anybody think about something like this or has implemented in
proprietary systems?

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: garbage-free java.nio

[Roman Leventov]

one.nio.net package of one-nio library (
https://github.com/odnoklassniki/one-nio/tree/master/src/one/nio/net) is
basically a reimplementation of java.nio. It does less locking, and, I
suppose, allocates less garbage. You may find it useful.

On 12 March 2018 at 15:38, Michael Guyver  wrote:

> On Sunday, March 11, 2018 at 8:25:32 PM UTC, John Hening wrote:
>>
>> recently I am interested in non-blokcing java api for networking. It
>> seems to be great. However, I would like to implement garbage-free
>> solution. I am trying to do it only for learning purpose (I know that I
>> don't implement a "better" solution). Especially, my solution is going to
>> be garbage-free.
>>
>
>  Hi John,
>
> I've looked intot this as part of a toy project and as Martin says you end
> up with JNI. At that point you could just as easily hand-off the networking
> layer to something like libev and be done with it, depending on your needs.
>
> Of course, a 0-GC TLS (client) in Java is a real ask. ;)
>
> Regards
>
> Mike
>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Safepoints, memcpy, and Unsafe.copyMemory

[Roman Leventov]

Has this problem been fixed in OpenJDK?

https://bugs.openjdk.java.net/browse/JDK-8149596 description says that 
"JDK-8141491 moves the copy functionality from libjava.so/Bits.c into the 
VM and Unsafe. The wrapper methods are no longer needed and the nio code 
should be updated to call them directly instead." However I cannot find any 
code that looks like safepoint poll insertion or copy chunking neither in 
Unsafe.java 
(http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/file/d54486c189e5/src/java.base/share/classes/jdk/internal/misc/Unsafe.java),
 
unsafe.cpp 
(http://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot/file/22d7a88dbe78/src/share/vm/prims/unsafe.cpp),
 
nor copy.cpp 
(http://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot/file/22d7a88dbe78/src/share/vm/utilities/copy.cpp).

On Thursday, 25 July 2013 09:47:34 UTC+2, Peter Lawrey wrote:
>
> > This can have all sorts of BAD consequences including hitting the OOM 
> killer.
>
> You would have to be pretty close to the OOM killer's limit.  I suspect 
> the assumption is that you don't creates lots of these and you are no where 
> near your process limits.
>
> BTW If you can see better ways of doing this, you really should submit 
> RFEs. ;)
>
>
> On 25 July 2013 04:57, Kevin Burton  
> wrote:
>
>> Actually... there's a bug in the JVM here.
>>
>> They allocate capacity + pageSize but only 'reserve' capacity.  
>>
>> This means that one MAX_DIRECT_MEMORY isn't yielded correctly and you 
>> could actually allocated MORE direct memory than allowed.
>>
>> This can have all sorts of BAD consequences including hitting the OOM 
>> killer.  
>>
>> I'm really surprised by the sever LACK of quality in a lot of this code. 
>>  I think a lot of it doesn't see the light of day and when you dive into it 
>> you really start to see lots of breakage.
>>
>> I've found 2-3 pretty severe problems in this code.
>>
>> Makes me think I should look at the source of Unsafe too.
>>
>>
>> On Wednesday, July 24, 2013 8:51:24 PM UTC-7, Kevin Burton wrote:
>>>
>>> Ah...  Actually yes.  Diving into it DirectByteBuffer does align some 
>>> cache alignment.
>>>
>>> Here's the code in question from JDK 1.7:
>>>
>>> https://gist.github.com/burtonator/6076790
>>>
>>> Very interesting!
>>>
>>> On Tuesday, July 23, 2013 9:49:58 PM UTC-7, mikeb01 wrote:

 It's word aligned but not cache aligned, if some of your operations 
 are straddling cache-lines you could be paying some extra cost there. 

 Mike. 

 On 24 July 2013 16:45, Kevin Burton  wrote: 
 > I think I'm going to verify this just to be sure. 
 > 
 > But Unsafe's documentation says that it's aligned. 
 > 
 > Here's a good deep dive into this topic btw: 
 > 
 > http://psy-lob-saw.blogspot.com/2013/01/direct-memory-
 alignment-in-java.html 
 > 
 > On Tuesday, July 23, 2013 9:10:22 PM UTC-7, mikeb01 wrote: 
 >> 
 >> You may want to compare the alignment of the DirectByteBuffer and 
 the 
 >> memory allocated by Unsafe. 
 >> 
 >> Mike. 
 >> 
 >> On 24 July 2013 15:11, Kevin Burton  wrote: 
 >> > I got sucked into writing my own implementation which its really 
 JUST 
 >> > Unsafe… but I'm trying to avoid the lock in Bits since I do lots 
 of 
 >> > small 
 >> > allocations. 
 >> > 
 >> > What's interesting is that my benchmarks show that Unsafe is 
 *slightly* 
 >> > slower than a LITTLE_ENDIAN DirectByteBuffer.  I'm not sure why… 
 I'm 
 >> > going 
 >> > to work on some code to get the benchmark smaller to see what's 
 up… it's 
 >> > not 
 >> > AMAZINGLY slower… maybe like 5%.  I just expected Unsafe to be 20% 
 or so 
 >> > faster. 
 >> > 
 >> > Another benefit is that you can work with >2GB mmap files or 
 memory 
 >> > slabs. 
 >> > And in my use case that's another perk! 
 >> > 
 >> > On Tuesday, July 23, 2013 7:53:12 PM UTC-7, Vladimir Rodionov 
 wrote: 
 >> >> 
 >> >> I have never seen any real issue with Unsafe.copyMemory (except 
 the 
 >> >> fact 
 >> >> that it is not supported in some OpenJDK versions). It seems that 
 all 
 >> >> Unsafe 
 >> >> is rock solid. But we are still in development-testing phase of 
 the 
 >> >> product. 
 >> >> 
 >> >> Custom All Java Off Heap Memory Management is built entirely on 
 top of 
 >> >> Unsafe. Tested up to 240GB with 20M alloc/free per sec during 24 
 hours. 
 >> >> 
 >> >>  --best 
 >> >> 
 >> >> On Tuesday, July 16, 2013 12:45:34 PM UTC-7, Kevin Burton wrote: 
 >> >>> 
 >> >>> So I'm reading the JVM documentation dealing with copying memory 
 and 
 >> >>> Unsafe when I came across this: 
 >> >>> 
 >> >>> // This number limits the number of bytes to copy per call 
 to 
 >> >>> Unsafe's 
 >> >>> //