JEP draft

[Julian Waters]

I should mention that although this isn't in the JEP yet, the plan is to
have 2 different compilation modes available, "Profiling" for compilers
like C1 in Tiers 2 and 3, which is compiled profiling code that will work
in tandem with the Tiered Compilation execution pipeline that HotSpot
employs, meaning it can then be optimized even more as HotSpot collects
profiling data from it, and "Optimized" which is for compilers like C2 and
C1 in Tier 1. Such Ahead of Time code that is compiled as "Optimized" will
be treated as having been optimized to the best extent possible, and will
not be part of the optimization and deoptimization cycles like "Profiling"
code will be

On Fri, Jul 28, 2023 at 3:58 PM Julian Waters <tanksherman27 at gmail.com>
wrote:

> Hi Mike,
>
> Although the goal wasn't written with that in mind (the compiler
> independence is for code produced by JVMCI compilers, most notably to help
> what Galahad intends to do with the Graal JIT by AOT compiling it, rather
> than only restricting such code to only use C1 and C2), I suppose you could
> indeed use this platform to execute any arbitrary language with HotSpot,
> much in the same way any language can compile to Java's bytecode and
> execute in the Java Virtual Machine currently. The ABI is very probably
> going to be the same as what C1, C2, and JVMCI use, so any language that
> respects the same ABI as a JVMCI compiler could probably run with HotSpot,
> but again I will mention that this is not what the JEP was written in mind
> with. See also non-goals, which mentions that this feature will only be
> applicable to Java code (or any language trying to use this platform to
> compile to native) that respects the constraints that Leyden normally
> applies to its closed world standalone binaries
>
> best regards,
> Julian
>
> On Fri, Jul 28, 2023 at 3:26 PM Mike Hearn <mike at hydraulic.software>
> wrote:
>
>> Nice to see!
>>
>> Presumably the concrete goal will be to nail down an ABI between compiled
>> code and the HotSpot runtime services? The compiler independence of the
>> goals is quite interesting. In theory if there's a precise ABI for
>> accessing runtime services like the GC, reflection, deoptimization, TLS
>> etc, then you could write a new non-Java language that compiles to native
>> code ahead of time using some pre-existing compiler infrastructure (e.g.
>> .NET?), which then uses HotSpot almost as a normal language runtime
>> library. Minimal Java code would be executed in this model and you could
>> theoretically even use LTO to get rid of the bits of the JVM you aren't
>> using. So if you wanted to make a new GCd language but wanted to skip
>> bytecode and Truffle then you could do so, with a Leyden of that form.
>>
>> Or is the idea to go in some other direction?
>>
>> On Fri, 28 Jul 2023 at 04:41, Julian Waters <tanksherman27 at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> A JEP draft regarding Leyden has been submitted at
>>> https://bugs.openjdk.org/browse/JDK-8313278. Feedback is welcome
>>>
>>> best regards,
>>> Julian
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230728/bb9333ae/attachment.htm>