PT-166788647 FATE efficient maps #183

Merged
zxq9 merged 10 commits from PT-166788647-fate-efficient-maps into master 2019-08-13 22:51:14 +09:00
zxq9 commented 2019-08-13 18:54:51 +09:00 (Migrated from gitlab.com)

Created by: UlfNorell

Adds support for efficient maps in the contract state. This adds a new FATE value ?FATE_STORE_MAP(Cache, Id) containing a reference to a map saved in the state and a cache of updates to it. When writing the state we go over the terms and allocate store maps for (sufficiently large) maps and updates to old maps. See aeb_fate_maps:allocate_store_maps/2. Also some code for doing reference counting to enable garbage collection. The bulk of that code is in the aeternity PR.

Other minor things

  • Removes remote tail call instructions
  • Adds an arity argument to remote calls. Previously remote calls with wrong arity could mess up the stack, now they fail with a nice error.
*Created by: UlfNorell* - [PT-166788647](https://www.pivotaltracker.com/story/show/166788647) - aeternity/aesophia#121 - aeternity/aeternity#2646 Adds support for efficient maps in the contract state. This adds a new FATE value `?FATE_STORE_MAP(Cache, Id)` containing a reference to a map saved in the state and a cache of updates to it. When writing the state we go over the terms and allocate store maps for (sufficiently large) maps and updates to old maps. See `aeb_fate_maps:allocate_store_maps/2`. Also some code for doing reference counting to enable garbage collection. The bulk of that code is in the aeternity PR. Other minor things - Removes remote tail call instructions - Adds an arity argument to remote calls. Previously remote calls with wrong arity could mess up the stack, now they fail with a nice error.
zxq9 commented 2019-08-13 20:18:21 +09:00 (Migrated from gitlab.com)

Created by: hanssv

Review: Approved

*Created by: hanssv* **Review:** Approved
zxq9 commented 2019-08-13 22:33:09 +09:00 (Migrated from gitlab.com)

Created by: lucafavatella

So this may return a negative refcount? (While the type suggests otherwise.)

*Created by: lucafavatella* So this may return a negative refcount? (While the type suggests otherwise.)
zxq9 commented 2019-08-13 22:34:14 +09:00 (Migrated from gitlab.com)

Created by: lucafavatella

Not clear why not removed.

*Created by: lucafavatella* Not clear why not removed.
zxq9 commented 2019-08-13 22:34:19 +09:00 (Migrated from gitlab.com)

Created by: lucafavatella

Not clear why not removed.

*Created by: lucafavatella* Not clear why not removed.
zxq9 commented 2019-08-13 22:42:19 +09:00 (Migrated from gitlab.com)

Created by: lucafavatella

Review: Approved

Unclear possibility for refcount to be negative.

Unclear cost of small-to-large map.

*Created by: lucafavatella* **Review:** Approved Unclear possibility for refcount to be negative. Unclear cost of small-to-large map.
zxq9 commented 2019-08-13 22:49:57 +09:00 (Migrated from gitlab.com)

Created by: UlfNorell

Yes indeed. The type should really have integer() instead of pos_integer().

*Created by: UlfNorell* Yes indeed. The type should really have `integer()` instead of `pos_integer()`.
zxq9 commented 2019-08-13 22:51:14 +09:00 (Migrated from gitlab.com)

Merged by: UlfNorell at 2019-08-13 13:51:14 UTC

*Merged by: UlfNorell at 2019-08-13 13:51:14 UTC*
Sign in to join this conversation.
No description provided.