Condensers and Shading
Hi All, I just read through the early discussion on the condenser concept. A brain-worm I can't dispose of[1] is that the concept of time shifting could be used to allow language level shading. That is, if a user can say that none of the classes in a module will be reflected upon using dynamically constructed values.[2] Class.forName(f()); // X Then it would be a "safe" operation to change the package name of all of those classes and bundle them inside of a module which requires them.[3] shadeable module org.example { exports org.example; exports org.example.abc; } module org.other { requires shaded org.example; } Now, this is not in Leyden's mission statement. Nothing about startup time is improved by renaming packages and classes. But the set of information you'd need to allow shading seems to overlap with the set of information you'd need to allow for making a static executable. So in the same way Valhalla is converging towards T! + value + implicit constructor = inline-ability there might be a "can make static exe" that falls out of other features like this. [1]: And one I feel I should bring up considering that the set of condensers might start out or remain closed to keep a consistent platform definition. [2]: + some other restrictions I am sure [3]: There might be a place other than modules which could work, but module-info declarations are currently the only place where users explicitly mark reflect-ability constraints today, so it
There is no general way to know whether multiple instances of a library can coexist in the same process or in what mysterious ways attempting that will break (the instances could write to the same files, bind to the same port etc.). This is true for all languages. However, to the extent that is possible, modules already support this with layers; i.e. you already have the best possible “language level shading” you can hope for. The reason layers can only be configured programmatically is that the best possible is not good enough to recommend for wide use, but there are tools out there (e.g. https://github.com/moditect/layrry) that offer configuring layers with configuration files. — Ron
On 13 Jun 2023, at 10:16, Ethan McCue <ethan@mccue.dev> wrote:
Hi All,
I just read through the early discussion on the condenser concept.
A brain-worm I can't dispose of[1] is that the concept of time shifting could be used to allow language level shading.
That is, if a user can say that none of the classes in a module will be reflected upon using dynamically constructed values.[2]
Class.forName(f()); // X
Then it would be a "safe" operation to change the package name of all of those classes and bundle them inside of a module which requires them.[3]
shadeable module org.example { exports org.example; exports org.example.abc; }
module org.other { requires shaded org.example; }
Now, this is not in Leyden's mission statement. Nothing about startup time is improved by renaming packages and classes. But the set of information you'd need to allow shading seems to overlap with the set of information you'd need to allow for making a static executable.
So in the same way Valhalla is converging towards T! + value + implicit constructor = inline-ability there might be a "can make static exe" that falls out of other features like this.
[1]: And one I feel I should bring up considering that the set of condensers might start out or remain closed to keep a consistent platform definition. [2]: + some other restrictions I am sure [3]: There might be a place other than modules which could work, but module-info declarations are currently the only place where users explicitly mark reflect-ability constraints today, so it
A brain-worm I can't dispose of[1] is that the concept of time shifting could be used to allow language level shading.
It's quite possible; program transformation is a pretty general tool. However, I want to caution that Leyden's design center is around _semantic-preserving_ transformations. That is, a Java program has a meaning, and the transformed program should have the same meaning as the original. As you point out, the kind of information needed to make this transformation has a lot of overlap with the kind of information you need for dead code stripping, AOT compilation, reflection elimination, etc.
participants (3)
-
Brian Goetz
-
Ethan McCue
-
Ron Pressler