oracle / graal

GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
https://www.graalvm.org
Other
20.37k stars 1.63k forks source link

Support for Inspecting Available Stack Memory #3154

Open iamrecursion opened 3 years ago

iamrecursion commented 3 years ago

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:

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.

  1. Removing Stack Limits: Removing stack limits on the JVM altogether. This would make programming using recursion a first-class citizen on the JVM. The issue with implementing this is that it would likely require deep changes to HotSpot itself to support.
  2. Removing SVM Stack Limits: This would be a semantically breaking change between Substrate VM and HotSpot itself, but potentially the SubstrateVM platform is more amenable to such a change.

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!

munishchouhan commented 3 years ago

@iamrecursion thanks for the feature request We will check it out and update you

iamrecursion commented 3 years ago

Great, thanks!

chumer commented 3 years ago

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.

iamrecursion commented 3 years ago

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!