cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9608) Support Java 11
Date Mon, 23 Jul 2018 11:46:00 GMT


Benedict commented on CASSANDRA-9608:

{quote}I was racking my brain to see if there's an alternative to allocating an object on-demand
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.
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


> Support Java 11
> ---------------
>                 Key: CASSANDRA-9608
>                 URL:
>             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

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message