Get rid of TruffleBoundary in Map.insert and Map.get

[wdanilo]

This task is automatically imported from the old Task Issue Board and it was originally created by Pavel Marek.
Original issue is here.

---

A follow-up of https://www.pivotaltracker.com/n/projects/2539304/stories/181027272 - the previous story got bigger than we expected, so we have decided to split it.

EnsoHashMapBuilder.get is behind TruffleBoundary, because a black listed method is reachable from it. It seems that the usage of org.graalvm.collections.EconomicMap was not a good idea for a hash map implementation after all. I partially increased the performance by adding @TruffleBoundary(allowInline = true) on some places (bc953f9). Try to investigate the performance more, and ultimately, get rid of TruffleBoundary in Map.insert and Map.get altogether.

Tasks:

• Consider computing hashCode when computing == on Atom objects
• Functions shall not be comparable (only use "same object policy" as in NaN can be used as a key in Map #6301)
• NaNs aren't suitable keys as they aren't supposed to be comparable to themselves - done by NaN can be used as a key in Map #6301
• Demonstrate effective implementation of distinct via Map (for objects that don't provide custom == & co.)
• Show how to use the Enso Map from polyglot Java
• Investigate the performance of EnsoHashMap (details in the description)

For future

• Implement pattern matching for Map
• Migrate WithWarnings to use EnsoHashMap - Migrate WithWarnings to use EnsoHashMap to speed them up significantly #8682

Blockers:

https://www.pivotaltracker.com/n/projects/2539304/stories/181027272 resolved

[JaroslavTulach]

Brainstorming idea. The issue

• Report only unique warnings #6372

needs a partial evaluation friendly Map (or Set) of already attached warnings. It'd be great if we could share the same implementation with EnsoHashMap. At the end the needs of Vector.distinct and filtering of "warning duplicates" seem to be very similar.