search

basilTeam / basil

Fast and flexible language exploring partial evaluation, context-sensitive parsing, and metaprogramming. Compiles JIT or AOT to native code.
BSD 3-Clause "New" or "Revised" License
124 stars 11 forks source link

Vaporization instead of reference counting to jump to the close-to-metal language battleground #25

Closed dumblob closed 3 years ago

dumblob commented 3 years ago

Languages with advanced compile-time evaluation & compile-time syntax extensibility make it much easier to overcome restrictions imposed by some highly efficient memory management techniques.

Basil is such a language and thus I'd like to point out the Vaporization technique which might actually allow Basil to get rid of reference counting altogether if certain constraints will be implemented.

Vaporization also allows for real-time guarantees which makes the language more attractive in general.

Thoughts?

elucent commented 3 years ago

Reference-counting won't be persisting at actual runtime, it's just an implementation detail within the compiler. The eventual plan is to use a relatively simple copying collector, and to invest in good escape analysis + special-casing allocations (see this post of mine for a GC alternative) to avoid overstressing the heap.

The backend is the next major step for the rewrite (the frontend is largely done, at least in terms of difficult features/large systems), so hopefully this will manifest soon.

dumblob commented 3 years ago

Yep, I read that post (in Dec 2020 IIRC) - I just didn't catch from the C++ code that it's being used only for the compile-time metaprogramming. That's good news.

Btw. to the "stack overflow (due to recursion, loops, etc.)" issue one potential idea might be to mimick some of the behavior of a "virtual memory" - some ideas are used e.g. in the BipBuffer (e.g. https://github.com/jamesmunns/bbqueue ) I referenced in one of your last commits (though here we have a different situation).

dumblob commented 3 years ago

Btw. CPS as proposed in https://github.com/basilTeam/basil/issues/21 could almost entirely eliminate any stack overflows (by making it rather simple to determine the maximum possible stack depth in compile-time). See https://github.com/nim-works/cps/tree/master/docs as they finally managed to make it work seamlessly in Nim.

What do you think about this solution to stack management (of course combined with your heap avoidant memory management on stack)?

I'm a strong proponent of CPS as except for the stack size benefit & arbitrary stop/resume this is probably the most efficient way for parallel computation (as no state is shared).