Port ConcurrentSkipListMap from JSR-166

[mox692]

Still work in progress.

• port source
• port test

After porting this, we can port ConcurrentSkipListSet.

[mox692]

@WojciechMazur
This PR is still totally in progress, but could you just review this commit?

In jsr166, VarHandle is used to achieve atomic operation(source), but if I understand correctly, VarHandle or AtomicReferenceFieldUpdater are not currently implemented in scala-native.

So I use CAtomicRef and Intrinsics here, but I want to make sure this is the right way. (Perhaps SynchronousQueue etc. use the same trick?)

[WojciechMazur]

So I use CAtomicRef and Intrinsics here, but I want to make sure this is the right way.

Yes, that would be the correct way to workaround these issues. Instead of VarHandle use CAtomic as a wrapper for the underlying field pointer.

For AtomicFieldUpdaters they're partially supported, but not directly - we cannot use Java reflection-based API, however AtomicReferenceFieldUpdater and other are in fact defined as abstract class. We use this fact to implement their Intrinisc based version, without usage of reflection. It was used to make scala.collection.concurent.TrieMap work: definition, usage to port Java sources of stdlib defined here. And we test the API/JDK compliance here in unit-tests. However Intrinsic based Atomic Field Updaters are not yet defined in public API. In case of the ported source it should be fine, as it seems to be not using them, but I would try to create a ScalaNative specific API to create field updater without usage of intrinsics in users code. To some extent we might be able to do something similar with VarHandlers as well in the future.

Btw. LongAdder is not yet ported - it is using single-threaded implementation ported from Scala.js

[mox692]

Thanks for the detailed explanation! Ok, then I can proceed the porting the code related to varHandle.

LongAdder is not yet ported

Oops, I missed that. I'll port LongAdder in another PR before this.