[
https://issues.apache.org/jira/browse/IGNITE-6736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16292814#comment-16292814
]
Andrey Kuznetsov commented on IGNITE-6736:
------------------------------------------
I've made a naïve benchmark to compare performance of {{ReentrantLock}} and
Java monitor object synchronization in non-contended case. It was just a
single-threaded loop incrementing long non-volatile field 10^9 times with
various synchronizers. Results follow.
Java 8:
no sync: 1177ms
monitor/synchronized: 18804ms
monitor/unsafe: 64438ms
lock: 17103ms
Java 9:
no sync: 1183ms
monitor/synchronized: 18929ms
lock: 15193ms
I can't understand why {{ReentrantLock}} looks so good, but {{monitorEnter}}
and {{monitorExit}} are definitely slow. Possibly, [1] describes a reason for
this. Anyway, I'll change to locks with more confidence.
[1]
http://jsr166-concurrency.10961.n7.nabble.com/synchronized-vs-Unsafe-monitorEnter-monitorExit-tp11764p11767.html
> Java 9: rework GridCacheMapEntry synchronization logic to avoid
> Unsafe.monitor* methods
> ---------------------------------------------------------------------------------------
>
> Key: IGNITE-6736
> URL: https://issues.apache.org/jira/browse/IGNITE-6736
> Project: Ignite
> Issue Type: Task
> Components: cache
> Reporter: Vladimir Ozerov
> Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> {{GridCacheMapEntry}} class rely on {{synchronized}} on itself heavily. In
> {{ATOMIC}} caches we lock multiple entries at once using
> {{Unsafe.monitorEnter/Exit}} methods. Unfortunately these methods were
> removed in Java 9. Recursion is not an option, as it would cause stack
> overflow for {{putAll}} operations with multiple entries.
> Possible fixes:
> 1) Rework {{synchronized}} to {{ReentrantLock}}. Easy, but may cause
> additional memory pressure.
> 2) Have different implementations for Java 8 ({{synchronzied}}) and Java 9
> ({{ReentrantLock}}) - much more complex solution, because we will require
> separate module for Java 8 and Java 9.
> 3) Rework {{ATOMIC}} caches, so that {{putAll}} operation updates entries
> one-by-one. As a side effect it will eliminate deadlocks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
