New implementation of LinkedHashSet/LinkedHashMap

[joshlemer]

Recently, @szeiger rewrote the implementations of mutable.HashMap and mutable.HashSet here. So far as I see there's no reason not to implement LinkedHashSet/Maps the same way, and in fact doing so will allow LinkedHashMaps/Sets to participate in hashcode sharing between:

• s.c.i.HashMap
• s.c.i.HashSet
• s.c.i.VectorMap
• s.c.m.HashMap
• s.c.m.HashSet
• s.c.m.HashMap#keySet
• s.c.i.HashMap#keySet
• s.c.i.VectorMap#keySet

as started here

[joshlemer]

@szeiger would you approve this?

[szeiger]

I haven't paid much attention to LinkedHashMap so far. I think any performance improvement would be welcome, especially if we can share code again with the new HashMap implementation.

[mghildiy]

I would like to contribute here.

[joshlemer]

@mghildiy it's all yours if you want it 😄

[adriaanm]

Is this still under consideration for RC1?

[mghildiy]

I went through mutable.HashMap and found changes broadly as:

• mixesin trait mutable.AbstractMap

• Class level parameters added: initialCapacity: Int, loadFactor: Double

• Replaced HashTable field with Array named: private[this] var table = new ArrayNode[K, V]

• field 'contentSize' intoduced

• method 'size' overriden

• inline method 'computeHash' added

• inline method 'index' added

• inline metod 'findNode' added to find an entry for input key(k) in array 'table'

• API methods overriden: sizeHint, addAll, remove

• abstract iterator class HashMapIterator added

• private classes Node, DeserializationFactory added

• Modified methods: apply, getOrElse, getOrElseUpdate, put

[szeiger]

"changes" is an understatement - it's a completely new implementation. I think the idea here is to start with a copy of the new HashMap implementation and make the required changes for keeping track of the links.

[joshlemer]

@mghildiy @szeiger is right, as well as for LinkedHashSet

[mghildiy]

Thanks for the inputs.

[pavelpavlov]

I would also like to contribute if there's need for it.
We use linked collections in our code very heavily.

[mghildiy]

Some methods like writeObject, readObject are never called in current implementation of LinkedHashMap.
I would remove them.
Also any other code too which may not be needed as now many implementations would be inherited from HashMap.

[joshlemer]

@mghildiy actually those methods are being used, these are kind of "magic methods" that Java knows to call during Java serialization/deserialization. Also I would recommend not extending hashmap to implement linked hash map, but maybe some of the hashtable code can be factored out for reuse.

[mghildiy]

OK, so you mean a better approach would be to pull out reusable code from mutable.HashTable into a class/object and use it in classes wherever needed, like those enlisted in original post.
PS: Extending HashMap is approach also used in java''s LinkedHashMap.

[mghildiy]

As far as I understand, new implementation of HashMap/HashSet no more has hashtable related code.

[mghildiy]

Hi,

Any more inputs here?

[joshlemer]

@mghildiy If I were doing it, I would simply copy paste mutable.HashMap as LinkedHashMap and make necessary changes to make the nodes linked (taking the linking logic from the current LinkedHashMap), and same for LinkedHashSet

[joshlemer]

@mghildiy the first step to changing the mutable.HashMap code into LinkedHashMap would be to change its private Node[K, V] class to include fields var earlier: Node[K, V], var later: Node[K, V]

Let me know if you have any more questions 😄

[mghildiy]

Thanks for the inputs @joshlemer . Would look into it this weekend.

[mghildiy]

There are some methods,like apply, which are not implemented in current version of immutable.LinkedHashMap, but they are there in immutable.HashMap.
Should they be implemented?

[SethTisue]

some methods [...] are not implemented

you mean because the implementations are inherited? in many cases the inherited implementations are fine and there's no reason to override them. concrete collections may override some of them, usually for efficiency

[mghildiy]

Sorry, my mistake. I was actually referring to mutable versions, not immutable..

[mghildiy]

I am done with changes in LinkedHashMap.
Do I need to write a benchmark class too, jst like done for HashMap?
Also, currently there is a single test for LinkedHashMap(in LinkedHashMapTest.scala). Should I add tests for entire code in LinkedHahsMap.scala?

[joshlemer]

Do I need to write a benchmark class too, jst like done for HashMap?

No not necessarily,

Also, currently there is a single test for LinkedHashMap(in LinkedHashMapTest.scala). Should I add tests for entire code in LinkedHahsMap.scala?

I think if you just get all existing LinkedHashMap tests to pass, that should be enough to put up a preliminary [WIP] pull request

[adriaanm]

👋 I haven't seen a PR for this yet. As we're closing in rapidly on the RC1 due date, I'm going to have to defer this unless we can have a PR in a mergeable state this week or early next.

[mghildiy]

I am facing 2 test failures for my change. Trying to find the cause.

[SethTisue]

@mghildiy sounds good enough for a WIP PR, maybe if we take a look at it, it'll be obvious to somebody where the failures might be coming from

[mghildiy]

I would create a PR in next 2-3 days.
BTW, WIP PR is just like any other PR..right? May be it just has a WIP tag?

[SethTisue]

May be it just has a WIP tag?

right, or you can use GitHub's new "draft" feature, https://github.blog/2019-02-14-introducing-draft-pull-requests/

[mghildiy]

Draft PR:
scala/scala#7839

[joshlemer]

Thanks a bunch @mghildiy 😄

[adriaanm]

It seems this PR won't be ready this week, which is the deadline for RC1. I'm going to put this on the backlog, since it doesn't sound like something we could do in 2.13.1. I haven't followed in detail, so please correct me if I'm missing something.

[SethTisue]

the PR seems abandoned...? perhaps someone else would be interested in picking it up?