Hi, the port passes now the basic continuation tests jdk/jdk/internal/vm/Continuation/Basic.java with UseContinuationFastPath disabled.
Actually all tests in hotspot_loom and jdk_loom succeed except for 2 of them where the held monitor count is wrong (potentially caused by [1]) and another one with a method that is not compileable. The current version can again be found here: https://github.com/reinrich/loom/commits/ppc_port Richard. [1] https://bugs.openjdk.org/browse/JDK-8286957 From: Reingruber, Richard <richard.reingru...@sap.com> Date: Thursday, 2. June 2022 at 13:38 To: jdk-dev <jdk-...@openjdk.java.net>, porters-...@openjdk.java.net <porters-...@openjdk.java.net>, loom-...@openjdk.java.net <loom-...@openjdk.java.net> 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