JEP draft

[Mike Hearn]

Understood, I was just observing that it might be possible. I guess it
really would depend on how well documented the interface is. If it's
clearly documented and relatively stable, others could use it. If not, then
nobody would try. As far as I know the ABI that compiled code must conform
to in HotSpot isn't currently documented anywhere?

On Fri, 28 Jul 2023 at 09:58, 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/0cbb1d9f/attachment.htm>