Open iamrecursion opened 3 years ago
@iamrecursion thanks for the feature request We will check it out and update you
Great, thanks!
We are currently working on implementing stack size and limit for a different feature. Whether we want to expose it as an API is not yet clear. If we understand the feature well enough we can make an educated decision whether we can expose it. You probably also want to have a very efficient, ideally almost free, stack check. So what you probably want a:
if (hasFreeStackSpace(1024)) {
// continue to use stack
} else {
// try to unwind stack
}
instead, right?
The alternatives sound very far out, even for SVM. Implementing unbounded stacks is not trivial. However, i think there is a possibility we need this anyway for project Loom, as Loom will bring segmented stacks, as far as I understand it.
We are currently working on implementing stack size and limit for a different feature. Whether we want to expose it as an API is not yet clear. If we understand the feature well enough we can make an educated decision whether we can expose it. You probably also want to have a very efficient, ideally almost free, stack check. So what you probably want a:
if (hasFreeStackSpace(1024)) { // continue to use stack } else { // try to unwind stack }
instead, right?
Correct. A primitive like this would allow us to make an informed decision about when to spawn a new thread / fiber / what have you. The idea behind the getStackSize()
and getStackUsage()
above was mainly to do getStackSize() - getStackUsage()
after all!
The alternatives sound very far out, even for SVM. Implementing unbounded stacks is not trivial. However, i think there is a possibility we need this anyway for project Loom, as Loom will bring segmented stacks, as far as I understand it.
That makes a lot of sense, yes!
Feature Request: Stack Memory Inspection
Certain programming languages such as Haskell and Go provide their users with dynamically resizing unbounded stacks for executing their programs. This is a particular boon for functional languages (such as Haskell or Enso) where recursion is used to perform iterative processes, instead of explicit imperative loops.
In order to implement unbounded stacks on a platform with bounded stacks it is necessary to be able to introspect the current size of the stack, and hence calculate how much stack memory is remaining. Knowing that you are about to run out of stack can allow the guest language (prior to making a function call) to inspect the stack memory and to expand it (e.g. by spawning a new thread, or hopefully in the future a fiber).
Ideal Solution
The ideal solution to this problem would be for the Truffle API to expose methods for introspecting the stack size and stack usage to language implementors:
getStackSize()
would get the maximum stack size for the thread on which it is run.getStackUsage()
would return the amount of stack memory currently allocated for the thread on which it is run.Parties that Benefit
This is primarily a feature for language implementors, giving them more freedom to implement the desired semantics for their language on top of the Truffle framework. This, in turn, allows these language implementors to provide a better user experience to the users of their languages.
Alternatives
There are two primary alternatives to an API-based approach like the one outlined above, but they seem to me like they would involve more in-depth changes.
Contributing
I'd definitely be interested in contributing to add this feature, though it might sit on the backburner for a bit due to work being very busy!