cleaner api

[mgood7123]

how might we implement a cleaner api similar to Java while also considering MPS's current limitations and intended usage ?

Finalization and Weak, Soft, and Phantom References (docs.oracle.com/en/java/javase/20)

JEP 421: Deprecate Finalization for Removal (openjdk.org/jeps)

JAVA 20 - java.lang.Cleaner (docs.oracle.com/en/java/javase/20)

Java Cleaners (java/basics/java-cleaners - how to use)

(tho such api would be more time consuming to specify with an object class compared to simply registering for finalization and then handling the finalization)

also while not everything in jvm's gc applies to MPS, some concepts should be noted

(such as weak references needed by dylan, possibly originally inspired by java or some other language that provides them, and then ported over to and implemented in dylan, and then made public via MPS)

[rptb1]

One significant think about JVM finalzation that you will have read is that they're removing it. And for good reason. The same reasons, in fact, that I described in #259 (comment) . All GCs have the same issue: when you provide finalization (which is based on memory) people start to press it in to use to reliably manage external resource. It is not a suitable tool for that. I'm sure the Java people have realized this and decided to remove it.

You'll note that registering objects for "cleaning" is basically like mps_finalize() and cleaning actions are basically run when the equivalent of mps_message_type_finalization() is received.

On a historical note, Dylan was a direct competitor to Java, and was originally supported by Apple. But Java won the game. The MPS pre-dates Java and its design owes more to the Lisp Machine than Java. Nothing in Dylan was "ported over" from Java. Most of it was inherited from Lisp and Scheme. Harlequin, the company that developed Dylan (and originally the MPS) was a major Lisp vendor.

[rptb1]

The MPS external interface is a fairly thin layer on top of the MPS internal workings. We have not developed a lot of "convenience" functions on top. An example of such convenience would be automatic root discovery (similar to the BDWGC). This is partly because the main applications of the MPS have been in the run-time libraries of programming languages -- part of the back end of compilers. The MPS is not necessarily well designed to be used directly by programmers in applications.

We'd definitely like to have such a layer, though.

[mgood7123]

On a historical note, Dylan was a direct competitor to Java, and was originally supported by Apple. But Java won the game. The MPS pre-dates Java and its design owes more to the Lisp Machine than Java. Nothing in Dylan was "ported over" from Java. Most of it was inherited from Lisp and Scheme. Harlequin, the company that developed Dylan (and originally the MPS) was a major Lisp vendor.

Wow

[mgood7123]

You'll note that registering objects for "cleaning" is basically like mps_finalize() and cleaning actions are basically run when the equivalent of mps_message_type_finalization() is received.

Doesn't this contradict itself?

[mgood7123]

Welp, even though resurrection is very undesirable

it CANNOT be obliterated since there are valid use cases for it

such as COM/STA interop and apple api interop (very strong calling-thread requirements)

[rptb1]

Added pending label so we can consider improvements to documentation.