Hi Andrey, Considering that Java 8 became the default version Ignite works on, I don’t see why we should keep the mentioned classes and fully support your initiative.
— Denis > On Jan 26, 2018, at 7:45 AM, Andrey Kuznetsov <[email protected]> wrote: > > Hi Igniters! > > I'm revising org.jsr166 package contents now. Ideally, we should get rid of > it completely. As far as I see some classes can be transparently replaced > by Java8 equivalents, some other can reuse standard Java8 versions, and > some can't be removed at all. I'd like to discuss this. > > 1. LongAdder8, ThreadLocalAdder8, ConcurrentHashMap8 [1], [2]: > These can be simply replaced by their j.u.c equivalents. > > 2. ConcurrentLinkedHashMap [3]: > Originally this was a mix of two JSR166 classes: ConcurrentHashMapV8 and > ConcurrentHashMap, as they looked like at some time between late 2011 and > mid-2012, but before CHMV8 was merged into CHM in August, 2012. Then > ConcurrentLinkedDeque8 was added to stitch the structure with a list. Later > there were made some significant performance improvements to Segment > (partial hash table) inner class, BTW Segments were removed from CHM > implementation upon CHMV8-to-CHM merge. Taking this story into account I'd > like to leave this extremely customized class unchanged. > > 3. ConcurrentLinkedDeque8 [4]: > This one is very similar to standard ConcurrentLinkedDeque, but has a > couple of differences. First, LongAdder was attached to provide fast size() > method. Second, queue Node was exposed as public declaration. Latter > feature is used extensively in EvictionPolicy implementations. As for me, > the only benefit of this is CAS logic in unlinkx() method. And this logic > relates to concrete data item being stored in a queue, but not to queue > itself. So one can hide Node back and add AtomicBoolean (as one of the > possible options) to queue item along with EvictableEntry. Ultimately, we > can extend standard ConcurrentLinkedDeque by adding faster size() and get > rid of unlinkx() and other ***x() stuff. Yet another consumer of unlinkx() > method is MemoryEventStorageSpi, one can fix it the same way as eviction > policies, however only logging is affected there, so I'm unsure if we need > to fix it at all. > > I'll appreciate your thoughts on the subject. > > > [1] https://issues.apache.org/jira/browse/IGNITE-7518 > > [2] https://issues.apache.org/jira/browse/IGNITE-7513 > > [3] https://issues.apache.org/jira/browse/IGNITE-7516 > > [4] https://issues.apache.org/jira/browse/IGNITE-7517 > > > -- > Best regards, > Andrey Kuznetsov.
