From 463e33fa2c231d39bbe682e9ded3b8e991975dc9 Mon Sep 17 00:00:00 2001 From: Jaroslav Tulach Date: Sat, 2 Mar 2024 07:45:55 +0100 Subject: [PATCH] Done: Static Methods on Types, Unboxed Atoms, Unboxed Vectors, Parser --- docs/runtime-roadmap.md | 68 +++++------------------------------------ 1 file changed, 7 insertions(+), 61 deletions(-) diff --git a/docs/runtime-roadmap.md b/docs/runtime-roadmap.md index a0285026e9f6..97229428d012 100644 --- a/docs/runtime-roadmap.md +++ b/docs/runtime-roadmap.md @@ -14,20 +14,11 @@ priority, but the dependencies between tasks are described. ## Technology Choices -With the advent of Java 17 and its ergonomic improvements (read: -pattern-matching), it makes little sense to retain the usage of Scala throughout -the compiler. The language was originally introduced due to the capabilities of -its type system in comparison to Java's, but very little of this functionality -has been used in the end. - -We recommend moving everything to Java as part of this work, as you will end up -with better tooling support. Scala has been a problem child. - -Enso originally started working with Java 8, and was transitioned (painfully, -due to the JPMS) to Java 11. Java 8 was EOL'd by the graal team after a couple -of years. It seems likely that Java 11 will suffer a similar fate, though the -transition from 11 to 17 will be far less painful as it doesn't introduce any -breaking language-level changes. +Enso interpreter is written in a mixture of Scala and Java. Scala was originally +used due to the capabilities of its type system in comparison to Java's. Modern +Java (as provided by JDK 21 or [Frgaal compiler](http://frgaal.org)) meets most +of the needs too. The ultimate goal is to write everything in Java and also keep +up with most recent long term supported JDK/GraalVM releases. ## Static Analysis @@ -49,7 +40,8 @@ Currently, the IR is: - Very verbose and difficult to add a new node to. Adding a new node requires adding ~100 lines of code that could likely be automated away. Lots of boilerplate. -- Of unknown performance. +- Of poor performance as witnessed by + [static compiler benchmarks](https://github.com/enso-org/enso/pull/9158) - Partially mutable, making it confusing as to which things are shared. A new IR for Enso would have to: @@ -252,25 +244,6 @@ To rectify this situation, we recommend implementing a system we have termed With this done, it may still be necessary to create a Java DSL for implementing built-in methods and types, but that is unclear at this point. -### Static Methods on Types - -Currently, Enso allows calling methods on _modules_, _constructors_, and -_instances_. This does not conform to the language specification because it -allows constructors and instances to be treated the same at runtime. This leads -to odd results (see the ticket below). - -The end result should be compliant with the design described -[here](https://github.com/enso-org/enso/issues/1851), and needs to be taken into -account when defining builtins. - -### Better Safepointing - -Enso currently uses a hand-rolled safepointing system for interrupting threads -and handling resource finalisation. With 21.1, Truffle landed its own system for -doing this. Enso should be updated to use -[the new system](https://github.com/oracle/graal/blob/master/truffle/docs/Safepoints.md), -instead, as it will provide better performance and more robust operation. - ## Runtime Performance While Enso is performant when it gets JITted by GraalVM, the performance when @@ -290,29 +263,6 @@ This can be greatly improved. be improved. - Many of the above-listed static optimisations will greatly help here. -### Unboxed Atoms - -Currently every atom in Enso is stored boxed. In limited circumstances it may be -possible to unbox these and hence remove the indirection cost when accessing -their data. - -- Read the details of Truffle's - [`DynamicObject`](https://www.graalvm.org/truffle/javadoc/com/oracle/truffle/api/object/DynamicObject.html), - and the sources. -- Use this system to inform the design for a system that reduces the overhead of - dynamic field names and arities when accessing data on Atoms. - -### Unboxed Vectors - -Enso currently doesn't have support for unboxed arrays (and hence vectors). This -means that it incurs a significant performance cost when working with pure -numerical arrays. This can be improved. - -- Read the truffle documentation on - [truffle libraries](https://github.com/oracle/graal/blob/master/truffle/docs/TruffleLibraries.md). -- Based on this, define a system that seamlessly specializes and deoptimises - between boxed and unboxed arrays as necessary. - ## IDE As Enso's primary mode of use is in the IDE, there are a number of important @@ -362,7 +312,3 @@ preprocessors. - Implement caching support for the visualization expression processing. - This cache should, much like the IDE's introspection cache, track and save the values of all top-level bindings in the visualization preprocessor. - -## Parser - -Parser