State of the ppc64le port of JEP 425: Virtual Threads (Preview)

[Remi Forax]

Hi Richard,
are you aware of JDK-8287496 ?
  https://bugs.openjdk.java.net/browse/JDK-8287496

It should help you to get a working first implementation for jdk 19. 

regards,
Rémi

----- Original Message -----
> From: "Reingruber, Richard" <richard.reingruber at sap.com>
> To: "jdk-dev" <jdk-dev at openjdk.java.net>, porters-dev at openjdk.java.net, "loom-dev" <loom-dev at openjdk.java.net>
> Sent: Thursday, June 2, 2022 1:38:19 PM
> Subject: State of the ppc64le port of JEP 425: Virtual Threads (Preview)

> Hi,
> 
> I learned today that preview features _must_ be implemented by a port in an
> OpenJDK release [1].
> 
> Unfortunately I have to inform you that I don't think the ppc64le port I'm
> currently working on will be ready in the JDK19 time frame.
> 
> When I started the work (Jan. or Dec. I think) I expected to finish it before
> summer. Even after the last status update [2] I thought I could make it. But
> with the difficulties I still experience and being 6-8 weeks out of office in
> summer it is now rather unlikely. And until this morning myself (and actually
> also my colleagues) assumed this would only be a minor issue.
> 
> Current Status of the Port:
> 
> * UseContinuationFastPath is disabled
> 
> * Basic tests where sequences of interpreted and compiled frames with quite some
>  variations are frozen and thawed succeed.
>  
> * GC with stack chunks on the java heap succeed.
> 
> * Basic exception handling tests succeed.
> 
> * Basic tests exercising compiled java calls with stack arguments succeed but
>  need to be revisited because there are issues.
> 
> [3] is a selection of test cases that I use in development.
> [4] is the most recent version of the ppc64le port
> 
> Main Technical Problems
> 
> * Shared code makes use of the 'unextended sp' of java frames. This breaks the
>  platform abstraction as it makes assumptions on where to find, e.g., stack
>  arguments relative to the unextended sp.
>  
> * There are non-obvious interdependencies in the code which make it difficult to
>  fix an issue. In an attempt to fix a problem I often have regressions because
>  I missed adaptations of dependent parts. And then it it is extremely tedious
>  to find the cause of the regression running tests and analyzing very long
>  trace output.
> 
> * Currently I see that the handling of stack arguments of compiled java methods
>  works in quite some cases (see [3]) but there are cases where it
>  doesn't. Trying alternative approaches means going through the tedious and
>  time consuming process described above.
>  
> * Lack of documentation. Heavily templatized implementation.
> 
> These problems (except the last) could not be foreseen. From a high level the
> port simply needs to copy frames between stack and heap and provide some
> assembler glue code. As I know now it is actually a high effort to get the
> deatils tuned right.
> 
> Thanks, Richard.
> 
> [1] Ports _must_ implement preview features in thread "What should the
> relationship between ports and developers of large projects be?"
>    https://mail.openjdk.java.net/pipermail/jdk-dev/2022-May/006635.html
> [2] State of the ppc64le loom port as of April 14
>    https://mail.openjdk.java.net/pipermail/loom-dev/2022-April/004197.html
> [3] BasicExp.java tests driving development of the port
>    https://github.com/reinrich/loom/blob/3286bc8b72401dbccac59c994919fc425a51cb52/test/jdk/jdk/internal/vm/Continuation/BasicExp.java
> [4] Most recent version of the ppc64le loom port
>     https://github.com/reinrich/loom/commits/ppc_port