-
-
Notifications
You must be signed in to change notification settings - Fork 416
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
More efficient object finalising implementation
Thanks to Sylvan and Andy Turley for their ideas. * The old finaliser implementation used the object hashmap to keep track of finalisers that needed to be run. This was not ideal because while the hashmap provides constant time operations, the constant time was still much larger than the time for a normal no finaliser allocation. Additionally, keeping track of finalisers in the object hashmap meant that every object with a finaliser would be added to the object hashmap even if it was only transient and never sent to another actor. This, once again, was different from normal allocations where the objects wouldn't be added to the hashmap until they were sent to another actor. The benchmark using ponybench showed that objects with finalisers were about 1 order of magnitude slower than objects without finalisers due to the overhead of using the object hashmap for tracking them. * The new finaliser implementation keeps the finaliser information in the chunk where the memory was allocated from. This is exactly the same as how non-finaliser allocations are tracked except for the additional work to keep track of the finaliser. The resulting benefit is that objects with finalisers will only get added to the object hashmap under the same circumstances as objects without finalisers. This gives us an increase in performance by 1 order of magnitude so that now objects with finalisers have the same allocation performance as objects without finalisers. * Keep a finaliser bitmap in chunk_t instead of an array of finaliser pointers. Run the finaliser from the pony_type_t->final_fn instead of storing/using the function passed in to pony_alloc_final. * Add pony_alloc_small_final and pony_alloc_large_final functions to avoid having to go through a branch and another function call to allocate memory with a finaliser. * Update compiler to call the appropriate one of pony_alloc_small_final or pony_alloc_large_final instead of pony_alloc_final.
- Loading branch information
Showing
11 changed files
with
300 additions
and
114 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.