Can you elaborate on  "native Perl compiler for the JVM"? Do you mean that it is part of and invokable by the JVM? Is that what enables Perl code to be executed from within Java applications?

Yes, the term "native" refers to how PerlOnJava compiles Perl code directly into JVM bytecode without relying on an interpreter or intermediary language. This means that every time Perl code is executed, whether as a main program, a module, or even within an eval block, it is translated into Java bytecode on the fly.

PerlOnJava is fully integrated with the JVM through its implementation of the Java Scripting API (JSR 223), which allows seamless execution of Perl code inside Java applications using the ScriptEngine interface. This capability makes it easy to invoke Perl from Java, opening up powerful possibilities for integration between the two languages. Moreover, there is an internal API, akin to the Perl XS API, that provides access to the inner workings of the Perl runtime within the JVM environment.

Does it also go the other way, in calling Java code from within Perl code, rendering Perl able to call libraries written in Java and as such able to leverage Java's vast ecosystem of applications?

Yes, PerlOnJava supports calling Java libraries from within Perl code, providing access to Java’s rich ecosystem. The cleanest and most maintainable way to do this is by defining a Perl class that integrates with Java, similar to how you would work with Perl XS. For example, the internal UNIVERSAL class in PerlOnJava is written in Java but registers itself as a Perl class, allowing seamless interaction between the two languages.

While there are other ways to call Java from Perl, such as language extensions, these approaches often come with trade-offs. Perlito, for instance, implemented several techniques to enable interaction with Java, but they sometimes rely on unconventional uses of Perl’s syntax, such as writing my Integer $x to declare a Java class. This breaks the portability and purity of the Perl language, which is why PerlOnJava avoids these techniques. Our goal is to maintain a clean, natural Perl experience while enabling Java interoperability. 

What version of Java can PerlOnJava emit? In the sense of whether it can take advantage of Java's newest constructs introduced after version 8.

PerlOnJava emits bytecode using the latest ASM library, ensuring compatibility with a wide range of Java versions. The project’s source code is currently set to Java 11, but it can easily be updated to newer versions as needed. PerlOnJava remains committed to leveraging modern Java environments and taking advantage of newer language features when appropriate, while maintaining broad compatibility.

Language runtime construction wise, what other advantages of having the JVM as a backend are there? For instance, can you plug into it to take advantage of its GC system?

Utilizing the JVM as a backend provides several notable advantages. For one, the JVM's built-in garbage collection and threading mechanisms are seamlessly integrated. This ensures efficient memory management and concurrency handling.

Additionally, the JVM ecosystem offers robust debugging and profiling tools through standard Java IDEs, which are invaluable for development and optimization.

Moreover, the JVM’s Just-In-Time (JIT) compiler enhances performance by dynamically optimizing frequently executed bytecode into native machine code. This optimization occurs after an initial warm-up period, allowing performance-critical sections of code to execute significantly faster.

As a side note, couldn't Raku just target the JVM as the backend? Why go through the trouble of making a new VM in the shape of MoarVM?

While targeting the JVM for Raku is possible, the choice to develop MoarVM was driven by several key considerations. The JVM, despite its robustness, has inherent limitations when it comes to fully supporting the advanced language features that Raku employs, such as its extensive metaprogramming capabilities, concurrency models, and custom syntax (grammars).

MoarVM offers a tailored environment that is specifically optimized for Raku’s needs. It allows for deeper integration and optimization at a lower level, providing greater flexibility and performance for features unique to Raku. By creating MoarVM, the Raku developers ensure that the language can leverage its full potential without being constrained by the JVM's architectural limitations.

Turning to Perl and threading. Perl's "interpreter threads" just provide a new Perl interpreter for each thread, and, by default, result in no data or state information being shared between threads. How does that play along the JVM ecosystem, considering that now Java comes with the new construct of Virtual Threads?

When integrating Perl into the JVM ecosystem, we can leverage Java's robust threading capabilities, including traditional Java threads, thread pools, and virtual threads. Virtual threads are lightweight, and they allow for a much higher concurrency level than traditional threads, making them well-suited for many concurrent workloads without the overhead of managing heavy OS threads.

Given this context, Perl's traditional threading model may not be the most natural fit for the JVM. Instead, it would make more sense to explore Java's native threading constructs, which are much more powerful and scalable. That said, we can also experiment with adapting Perl's threading model in ways that make sense in a JVM environment. For example:

• Shared State with Java Threads: We could explore making Perl’s variables or data structures accessible across threads using Java’s shared memory model and synchronization primitives. This could offer more flexibility than Perl’s current threading model, especially when dealing with larger, multithreaded applications.

• Virtual Threads for Scalability: Java's new virtual threads could provide a lightweight alternative to Perl’s "interpreter threads," allowing each Perl script or subroutine to run in a virtual thread without the overhead of creating separate interpreters. This could provide significant performance benefits in high-concurrency scenarios, such as web servers or background job processing.

• Alternative Concurrency Models: Beyond Java’s native threads, we could explore alternative concurrency models, such as actors (through libraries like Akka) or message-passing paradigms, to provide more sophisticated and scalable concurrency options for Perl programs in the JVM environment.

At this stage, the primary focus of PerlOnJava is to provide a solid Perl-to-JVM port, and threading extensions—whether in the form of traditional Java threads, virtual threads, or other concurrency models—will be explored as the project matures, depending on community interest and use cases.