[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16552702#comment-16552702
]
Benedict commented on CASSANDRA-9608:
-------------------------------------
{quote}I was racking my brain to see if there's an alternative to allocating an
object on-demand
{quote}
Well, it would be possible to implement our own variant of the JDK's internal
locking, which has a shared pool of locks that are allocated to a given object
on demand, but this would have to be done in unsafe territory. This would be
quite possible too, but it's more involved. I would be happy to have a crack
at it, but that's probably several days' work instead of a couple of hours.
{quote}A {{ReentrantLock}} would need to be allocated and used
"pessimistically" up-front - i.e. for every instance of
{{AtomicBTreePartition}}, so some non-negligible overhead to what we have now.
{quote}
Why do you suppose this to be the case? It only needs to be allocated on
demand, but then must persist after it has been allocated. The current
proposals have the following characteristics (which are approximately true; I
haven't been absolutely thorough, particularly for ReentrantLock, and have
fudged some context-specific things):
||Operation||Simple Condition||ReentrantLock||Inflating Lock 1||Inflating Lock
2||
|Quiescent memory overhead
(after contention)|0 bytes|60 bytes|0 bytes|32-bytes|
|First Uncontended lock()|1x CAS
24-byte allocation|60-byte allocation|1x CAS
32-byte allocation (or 48-byte, depending on choices)|1x CAS
64-byte allocation (or 80-byte, depending on choices)|
|Future Uncontended lock()|1x CAS
24-byte allocation|1x CAS|1x CAS
32-byte allocation|1x CAS
32-byte allocation|
|First Contended lock()|2x CAS
112-byte allocation|3x CAS
32-byte allocation|1x CAS
32-byte allocation|1x CAS
32-byte allocation|
|Future Contended lock()|1.5x CAS (only hop tail once per two additions)
64-byte allocation|3x CAS
32-byte allocation|1x CAS
32-byte allocation|1x CAS
32-byte allocation|
|Release|2x volatile write
1x volatile write + 1x unpark *_per_* waiting thread
_If > 1 waiting thread: *will incur all*_
_*contended lock() costs again*_|2x volatile write
1x CAS + 1x unpark *_if_* waiting thread|1x volatile write
1x volatile write + 1x unpark *_if_* waiting thread
1x CAS if no waiting threads (to deallocate safely)|1x volatile write
1x volatile write + 1x unpark *_if_* waiting thread|
There are other possible variants with different tradeoffs, for instance
reducing allocation costs for uncontended lock() in option (2) at possible
modest increase in CPU and implementation complexity. Again, I disclaim any
modest inaccuracies as didn't want to spend too long putting this together.
> Support Java 11
> ---------------
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
> Reporter: Robert Stupp
> Assignee: Robert Stupp
> Priority: Minor
> Fix For: 4.x
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - <dependency groupId="net.sourceforge.cobertura"
> artifactId="cobertura"/>
> + <dependency groupId="net.sourceforge.cobertura"
> artifactId="cobertura">
> + <exclusion groupId="com.sun" artifactId="tools"/>
> + </dependency>
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
