[CLOSED] Aion collection framework enhancements

[aionbot]

Issue created by yulongaion (on Tuesday Sep 04, 2018 at 20:58 GMT)

• [ ] Prototype hashmap
• [x] Optimize B+ tree insertion
• [x] Add missing exceptions
• [x] Implement "view" based iterator
• [ ] Add stream support

[aionbot]

Comment by JunhanHu-aion (on Wednesday Sep 05, 2018 at 20:38 GMT)

237 Prototype hashmap

In progress

217 Add missing exceptions

Done

[aionbot]

Comment by JunhanHu-aion (on Friday Sep 07, 2018 at 17:56 GMT)

Implement "view" based iterator Done with ba99ee8 4ac3083

[aionbot]

Comment by JunhanHu-aion (on Monday Sep 10, 2018 at 13:29 GMT)

After research, I think our current B tree insertion is good enough. "Eager" B tree insertion will result in around 3x of serilization cost and only benefit sequential order insertion. With random order insertion, our current insertion implementation performs better in term of energy.

However, i think there is something can be done for delete opeartion. Currently, each nodes (leaf and internal) are holding a pointer to its parent. Deletion operation relying on parent pointer to find common ancestor (we call it anchor). This parent pointer is not really nessary since we can solve the problem by introducing extra recursion parameters. This optimazion will result in an improvement of memory footprint (saving logn * 8 bytes).

[aionbot]

Comment by JunhanHu-aion (on Monday Sep 10, 2018 at 13:58 GMT)

Supporting java.util.stream is a tricky question. The following compents are identified

• Shadow java.util.stream Around 10 classes, and we can only supports sequential stream.
• Shadow java.util.function Around 40 interfaces, we need to identify the exact coverage we want. 10 classes will probably be enough. Research need to be done on how invoke dynamic interact with this class.
• Add collection support for stream Three existing aion collections.
• Energy metering for stream related opeartion We need to make sure function interface can be properly metered so user wont be able to bypass any energy cost. One other concern I have is "Stream" can be viewed as a programing style, it does now bring anything we can't already do to the table. If our energy metering for stream class is not good enough, people will always stay away from using it (If it is more expensive than plain iteration). Or people will always stick to it if it is cheaper.

I suggest we push it to further release since

• Lots of work
• Nothing new to the table

[aionbot]

Comment by JunhanHu-aion (on Tuesday Oct 30, 2018 at 13:49 GMT)

Close this since #237 and #217 are closed