Show HN: Micro-mitten – Research language with compile-time memory management • Hacker News Board

Re: Show HN: Micro-mitten – Research language with compile-time memory management

#11

Post by suyjuris » Fri, May 08, 2020, 2:22 PM UTC

flohofwoe wrote: post #2

> This means that it maintains the ability to insert freeing code at appropriate program points, without putting restrictions on how you write your code. How does the approach in mitten compare to Automatic Reference Counting in Objective-C (and I think Swift too)? From my experience, ARC can still add a surprising amount of memory management overhead to a program and needs a lot of hand-holding to keep that overhead…

> One thing I'd like to see in modern languages is to encourage and simplify working with an (almost) entirely static memory layout, and make manipulations inside this static memory layout safe.

This sounds interesting! What do you mean by (almost) static memory layout? Fixed sizes for everything in a contiguous region, or multiple growing arrays, or something else entirely?

In recent time I have written a few programs in a way that uses only realloc inside dynamic arrays for memory management and never frees. This leads to a big semi-global struct holding all the dynamic arrays, which I am reminded of. (Local functions can then take those arrays, use them, and give them back once they return.)

Re: Show HN: Micro-mitten – Research language with compile-time memory management

#12

Post by scott_s » Fri, May 08, 2020, 2:24 PM UTC

flohofwoe wrote: post #2

> This means that it maintains the ability to insert freeing code at appropriate program points, without putting restrictions on how you write your code. How does the approach in mitten compare to Automatic Reference Counting in Objective-C (and I think Swift too)? From my experience, ARC can still add a surprising amount of memory management overhead to a program and needs a lot of hand-holding to keep that overhead…

From the ASAP dissertation (https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf):

> Reference counting, like asap, is a safe, synchronous memory management strategy. However, rc approximates waste by unreachability which is less timely than asap’s approximation by Access.

I think a more careful reading of the work is required to distinguish the precise meanings of "unreachability" and "access" in this context.

Re: Show HN: Micro-mitten – Research language with compile-time memory management

#13

Post by zozbot234 » Fri, May 08, 2020, 2:30 PM UTC

xiaodai wrote: post #9

"In its current form, asap is not equipped to handle CONCURRENT programs. Managing memory in concurrent programs poses its own set of challenges." So it's doesn't have the fearless concurrency of Rust yet and I wonder if it's possible this approach at all. I guess it's an open research question.

Concurrency is a "proposed extension", per section 6.4 of the referenced thesis. Among other things, it is noted that cooperative concurrency with explicit yield points would be somewhat feasible, whereas anything more general than that is very much an active research area to say the least.

Re: Show HN: Micro-mitten – Research language with compile-time memory management

#14

Post by myu701 » Fri, May 08, 2020, 2:30 PM UTC

If a language like this were to take off, I could see linter-style errors pop up that are not currently possible.

"ERROR: maximum memory usage computed to be XYZ MB, which is higher than the speicified limit of 500MB"

Now that would help keep the RAM bloat down!

Re: Show HN: Micro-mitten – Research language with compile-time memory management

#15

Post by pietroppeter » Fri, May 08, 2020, 2:38 PM UTC

might be worth knowing that there is a production-deployed programming language which - besides being a great language in many, many respects - will very soon (next release) have compile-time memory management (already working and performant for stdlib including async) in a stable release: Nim.

[1] https://forum.nim-lang.org/t/5734#35562 [2] https://forum.nim-lang.org/t/6125#37829

Re: Show HN: Micro-mitten – Research language with compile-time memory management

#16

Post by flohofwoe » Fri, May 08, 2020, 2:42 PM UTC

suyjuris wrote: post #11

flohofwoe wrote: post #2

> This means that it maintains the ability to insert freeing code at appropriate program points, without putting restrictions on how you write your code. How does the approach in mitten compare to Automatic Reference Counting in Objective-C (and I think Swift too)? From my experience, ARC can still add a surprising amount of memory management overhead to a program and needs a lot of hand-holding to keep that overhead…

> One thing I'd like to see in modern languages is to encourage and simplify working with an (almost) entirely static memory layout, and make manipulations inside this static memory layout safe. This sounds interesting! What do you mean by (almost) static memory layout? Fixed sizes for everything in a contiguous region, or multiple growing arrays, or something else entirely? In recent time I have written a few progra…

I (mostly) returned to C a little while ago, and for smaller things I sometimes create the entire application state as a single, big struct that's made of many smaller nested structs, maybe with one or very few "layers" of dynamically allocated data dangling off from the static "root structure" (but only when really needed).

A very simple example is an all-in-one application data structure like this:

https://github.com/floooh/v6502r/blob/1d2b79ac11d7828b2722b5...

This very simple approach has some downsides of course, mostly because C doesn't help much to solve some problems like a more specialized language could (but on the other hand, it also doesn't get in the way much):

- Every part of the program sees and is allowed to change everything, so it would be nice to have a simple syntax for fine-grained visibility and access rules (but not at all like C++ public/private, more like compile-time read-only and read-write access tokens).

- Not much compile- and runtime-protection from code scribbling over neighboring nested structs.

- Not much flexibility for dynamic arrays. It would be good to have 3 flavors: (1) compile-time max capacity which can be completely embedded, (2) a runtime max capacity array, which is allocated once but can never grow, and (3) a fully dynamic array which can grow (but maybe never shrink?). Such dynamic arrays should never change their base address, so that memory locations remain stable.

- It's not well suited for bigger programs built from many modules. It should be possible to have highly modular program code, but still end up with a single monolithic "root data layout".

One great side effect of this approach is that it feels completely natural to not do dynamic memory allocation all over the place (and one of the good features of C is that memory allocation is always very obvious - and thus easy to avoid).

Re: Show HN: Micro-mitten – Research language with compile-time memory management

#17

Post by tayistay » Fri, May 08, 2020, 2:44 PM UTC

dwenzek wrote: post #4

It's refreshing to see new approaches for memory management exploring notably the power of static analysis at compile time. I will take the time to read this dissertation! Just a question. It reminds me previous works on static inference of stack-allocated regions. What are the relationships, if any? * [A Simplified Account of Region Inference]( https://hal.inria.fr/file/index/docid/72527/filename/RR-4104... ) * [MLt…

Interesting as well. I see the MLTon regions have issues with bounding space complexity. I wonder if a language could impose some reasonable restrictions to bound region space complexity. That would seem to make regions quite attractive.

Re: Show HN: Micro-mitten – Research language with compile-time memory management

#18

Post by _bxg1 » Fri, May 08, 2020, 2:55 PM UTC

myu701 wrote: post #14

If a language like this were to take off, I could see linter-style errors pop up that are not currently possible. "ERROR: maximum memory usage computed to be XYZ MB, which is higher than the speicified limit of 500MB" Now that would help keep the RAM bloat down!

As long as it still allows for arbitrary-length vectors - which I can't imagine it not - this would be impossible due to the halting problem. Or I guess, maybe you could derive a lower bound on memory usage, but you could not get an upper bound/exact number.

Re: Show HN: Micro-mitten – Research language with compile-time memory management

#19

Post by _bxg1 » Fri, May 08, 2020, 2:58 PM UTC

flohofwoe wrote: post #2

> This means that it maintains the ability to insert freeing code at appropriate program points, without putting restrictions on how you write your code. How does the approach in mitten compare to Automatic Reference Counting in Objective-C (and I think Swift too)? From my experience, ARC can still add a surprising amount of memory management overhead to a program and needs a lot of hand-holding to keep that overhead…

Reference counting happens at runtime, this happens at compile time.

Re: Show HN: Micro-mitten – Research language with compile-time memory management

#20

Post by Someone » Fri, May 08, 2020, 3:00 PM UTC

flohofwoe wrote: post #16

suyjuris wrote: post #11

Earlier quoted context omitted.

> One thing I'd like to see in modern languages is to encourage and simplify working with an (almost) entirely static memory layout, and make manipulations inside this static memory layout safe. This sounds interesting! What do you mean by (almost) static memory layout? Fixed sizes for everything in a contiguous region, or multiple growing arrays, or something else entirely? In recent time I have written a few progra…

I (mostly) returned to C a little while ago, and for smaller things I sometimes create the entire application state as a single, big struct that's made of many smaller nested structs, maybe with one or very few "layers" of dynamically allocated data dangling off from the static "root structure" (but only when really needed). A very simple example is an all-in-one application data structure like this: https://github.c…

Isn’t that just a variant on organizing your globals well to make using lots of globals manageable?

That’s what historically was done in languages such as FORTRAN and COBOL (both of which had compile-time memory management, but managed to do that by completely dropping memory allocation at runtime)

And yes, that meant dropping all dynamic memory allocation, too. If your wanted to run your FORTRAN program on a larger data set, you replaced the cards defining the dimensions of your arrays and recompiled.