fwsGonzo
commented
1 day ago Yep, the way memory works is indeed not clarified. But, I'll just mention it quickly that as long as the Sandbox instance is not destroyed, memory works exactly like you would expect. Technically we can serialize the sandboxes to restore them later too, but that API hasn't been exposed. And it's probably kind of expensive to use storage-wise.
Anyway, this deserves documentation indeed!
Can we clarify the lifecycle of the sandbox in relation to heap/state management?
Heap/State Overview:
Current Understanding:
Storage within the engine works as expected, much like it would in C++ applications, using standard C++ allocators.
There is native performance, with heap control occurring externally, meaning that allocating and deallocating resources in the VM behaves similarly to allocations in a C++ Godot extension.
Clarification Needed:
How is static data retained across instances, given that static variables in C++ persist across different calls and sessions?
Is static data stored within a dedicated memory block, and how is it accessed across different sandbox instances? An example illustrating this data persistence would be helpful.
Sandbox Lifecycle and Static Data
Current Understanding
The sandbox creates temporary engine objects (not temporary parameters, as might have been confused earlier), with access provided through
get_node()or similar functions.Clarification Needed
A section explaining the sandbox lifecycle would greatly improve understanding. Specifically:
When are temporary engine objects created and destroyed?
Where do static variables fit into the lifecycle—are they reset per session, or do they persist across the entire lifespan of the sandbox?
An example demonstrating the lifecycle of static data and temporary engine objects across multiple instances would be extremely useful.
Static Data and Memory Allocation
Allocator Insights
Since storage functions as expected, with native performance akin to standard C++ allocators, a brief section on basic heap management and memory allocation would be valuable:
How is memory allocated and deallocated in practice within the sandbox?
Are there any performance implications developers should be aware of when dealing with static data, or is heap/state management identical to a typical C++ program?
Additional Clarifications
Temporary parameters were previously mentioned, but it seems that this was a point of confusion. The correct term appears to be temporary engine objects, which aligns more closely with how the system handles temporary storage. Further clarification on this point could resolve lingering confusion.
Bonus:
A small example demonstrating how static data is created and held across different sessions within the sandbox.
An explanation on how heap allocation works for temporary engine objects and whether there are any special considerations for static data retention.