[External] : Re: Selectively Shifting and Constraining Computation

[Ron Pressler]

On 28 Oct 2022, at 23:25, Karsten Silz <karsten.silz at gmail.com<mailto:karsten.silz at gmail.com>> wrote:


On 28 Oct 2022, at 22:10, Ron Pressler <ron.pressler at oracle.com<mailto:ron.pressler at oracle.com>> wrote:

On 28 Oct 2022, at 08:19, Karsten Silz <karsten.silz at gmail.com<mailto:karsten.silz at gmail.com>> wrote:

These reasons may have influenced the decision to delay the standardizing of static executables in favor of optimizing Java first.

I couldn’t find anything in the document that says that the implementation of some condensers will be delayed in favour of others.

Sorry if that wasn’t clear: I was referring to the May announcement there: https://openjdk.org/projects/leyden/notes/01-beginnings

"So rather than adopt the closed-world constraint at the start, I propose that we instead pursue a gradual, incremental approach. We will explore a spectrum of constraints, weaker than the closed-world constraint, and discover what optimizations they enable. […] In the long run we will likely embrace the full closed-world constraint in order to produce fully-static images. Between now and then, however, we will develop and deliver incremental improvements which developers can use sooner rather than later.”

So I understood this as “Leyden will optimize Java first and later standardize fully-static images”. Am I wrong?

And my understanding of the October proposal is that it explains how these goals will be achieved. But it didn’t seem to change the plan of optimizing Java first. Please let me know if I missed something there!


Regards,
Karsten Silz


I don’t think you’re wrong in expecting that “standardising static images” would probably not be the *first* deliverable from Leyden, but I do think you’re wrong in concluding that that means it’s *delayed* (e.g. Project Loom delivered JEPs 353 and 373 in JDKs 13 and 15 respectively, so JEP 425, virtual threads, wasn’t Loom’s first deliverable, but it certainly wasn’t delayed by those JEPs). You’re reading “we believe we’ve found a way to deliver value at various points on the road to X” as “X is delayed”, and that’s a misinterpretation.

The document suggests that the work on investigating the concept of condensers — the thing that could eventually enable static images — will start right away (and may be done in parallel to developing specific condensers). Obviously, that work will need to get from where we are today to some point that’s some ways off, but the great news is that we may be able to deliver value on the way there.

I think your real question might be, “but I want feature X *now*; could you get there faster?” Like with many other OpenJDK projects, there's probably some “there” that we could get to faster, but that’s usually not where we’d like to end up.

BTW, I don’t understand what “optimising Java first” means. The work on optimising OpenJDK is constant; it neither starts nor ends with Leyden. Project Leyden, among other things, will support it.


— Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20221028/976741c8/attachment.htm>