Eliminating org.jsr166 from Ignite codebase

[Andrey Kuznetsov]

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.

[dmagda]

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 <[hidden email]> 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.