Performance Problems in the Kym Runtime Heap #28

New Issue

kayomn · 2023-07-22T13:58:18+02:00

kayomn commented

2023-07-22 13:58:18 +02:00

Because the Kym object heap is backed by coral.map.Slab acquire / discard within the runtime must first copy the whole object data from it, modify state, then copy it back in-place from the location it was removed from.

Because object data has a memory layout larger than most common register sizes (>64 bits), this means non-trivial copying. Further no data should need to be copied in and out from the first place as this is only because the Slab enforces safe access through the interface it provides.

The table could be accessed directly, much like the code does with uses of coral.list.Stack, however the indexing is non-trivial compared to Stacks because indices are not equivalent to keys and Slabs use a fragmented memory layout.

Since slabs are also a single contiguous memory block, this means they won't scale well as progressively more Kym Objects are allocated in memory.

For these reasons, a more specialized solution may be needed.

Because the Kym object heap is backed by `coral.map.Slab` acquire / discard within the runtime must first copy the whole object data from it, modify state, then copy it back in-place from the location it was removed from. Because object data has a memory layout larger than most common register sizes (>64 bits), this means non-trivial copying. Further no data should need to be copied in and out from the first place as this is only because the Slab enforces safe access through the interface it provides. The table could be accessed directly, much like the code does with uses of `coral.list.Stack`, however the indexing is non-trivial compared to Stacks because indices are not equivalent to keys and Slabs use a fragmented memory layout. Since slabs are also a single contiguous memory block, this means they won't scale well as progressively more Kym Objects are allocated in memory. For these reasons, a more specialized solution may be needed.

kayomn added this to the (deleted) milestone 2023-07-22 13:58:18 +02:00

kayomn added the

performance

label 2023-07-22 13:58:18 +02:00

kayomn changed title from ~~Unnecessary Copying in Kym Runtime Heap~~ to Performance Problems in the Kym Runtime Heap

2023-07-22 14:09:19 +02:00

kayomn commented

2023-08-12 16:19:18 +02:00

To update on this issue, much of the work in #30 was aimed at removing usage of Slab from Kym for the time being. This means every object creation is now a direct call to the underlying Allocator passed to the RuntimeEnv instance during initialization.

With that said, I still think the idea of the slab strategy makes a lot of sense given that the object types have a compile-time known, fixed size. I would like to re-investigate an approach where many fixed size slabs are created for object allocation, rather than a giant contiguous one for the whole virtual machine.

To update on this issue, much of the work in #30 was aimed at removing usage of Slab from Kym for the time being. This means every object creation is now a direct call to the underlying Allocator passed to the RuntimeEnv instance during initialization. With that said, I still think the idea of the slab strategy makes a lot of sense given that the object types have a compile-time known, fixed size. I would like to re-investigate an approach where many fixed size slabs are created for object allocation, rather than a giant contiguous one for the whole virtual machine.

kayomn commented

2023-11-05 16:56:03 +01:00

Removing this as a requirement of the scripting MVP.

kayomn removed this from the (deleted) milestone 2023-11-05 16:56:06 +01:00

kayomn commented

2024-06-05 00:58:53 +02:00

This is no longer applicable as the current implementation of CoralScript's heap is the underlying runtime allocator itself.

Maybe reintroducing some kind of object pool wants reviewing, but for now maximum performance isn't a priority.

This is no longer applicable as the current implementation of CoralScript's heap is the underlying runtime allocator itself. Maybe reintroducing some kind of object pool wants reviewing, but for now maximum performance isn't a priority.

kayomn closed this issue

2024-06-05 00:58:53 +02:00

Sign in to join this conversation.