Store IR caches in suitable format to read them "on demand"

[JaroslavTulach]

Pull Request Description

Major problem of #6100 is that we load 28MB of .ir caches at startup before doing anything useful. Rather than trying to speed up loading of all such data, we want to avoid loading of such a huge amount of data completely.

This PR introduces Persistance interface that can be registered for a particular Class (with or without its subclasses) and serialize and deserialize its instances via Persistance.Input and Persistance.Output. As serialization of most of the Scala case classes used by IR is very similar, there is an @Persistable annotation and associated annotation processor that can generate most of the boiler plate code automatically based on case class constructor signature.

Essential difference with respect to regular serde frameworks is the ability to load just a reference to an object without materializing it in the memory immediately. That allows creation of lazy sequences and their use in Method.Explicit that drastically cut out the amount of objects that has to be deserialized when loading .ir files.

Important Notes

There are many ways to improve this approach (see Future Work section), however measurements held on 177c44e indicate that there already is a speedup when executing simple:

from Standard.Base import IO

main = IO.println "Ahoj"

as regular 6cf75da version takes 4.3s while the version in this PR is able to finish in 3.6s. This clearly demonstrates the lazy deserialization is a viable approach which can deliver on the promise of restoring caches effectively.

Similar approach was suggested for Tree serde, but in the case of IR it makes even bigger sense. Most of the IR tree is not needed at early stage of the execution.

The advantaged of those manually written or annotation processor generated Persistance subclasses is their native image friendliness. There is no reflection and they should work with native image automatically.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Scala,
  Java,
  and
  style guides. - All code has been tested:
  • Unit tests have been written where possible.
  • reported as - Investigate why certain .ir files are bigger in the new format #8323
  • reported as - Avoid loading of MetadataStorage until it is needed #8324

Future Work

The Persistance format shall benefit from huge cache files mmapped into memory. Rather than having a lot of small .ir files for each module in standard library, let's have just a single file per each library. Btw. there already is such a file for BindingsMaps per each library - with the new format we can include whole IR in there.

Optimize for GC - so far this PR only loads objects lazily on demand, but once they are loaded, they are never freed. That could very likely be improved. Once the IR tree of a method is processed, it could be GCed. Lowering the memory requirements during execution.

[JaroslavTulach]

Use:

enso$ find lib/java/persistance/src/main/java/ | grep java$ | xargs /graalvm-21/bin/javadoc -d target/javadoc/ --snippet-path lib/java/persistance/src/test/java/

to generate target/javadoc/index.html and view this documentation in proper form.

[4e6]

It should be unnecessary

[4e6]

You can do javacOptons ++= Seq() the same way it is done for libraryDependencies

[4e6]

Just leaving it like that is error-prone. Someone will forget that access to the body triggers the serialization logic and it will hurt the performance. It should be reflected in the type signature

[JaroslavTulach]

I wanted to write a test to verify that the deserialization is lazy. I may do it in a subsequent PR.