JEP draft

[Julian Waters]

I suppose it could be an avenue to pursue as a sub-task of some sort ;)

On Fri, Jul 28, 2023 at 4:04 PM Mike Hearn <mike at hydraulic.software> wrote:

> 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/b98a34d1/attachment.htm>