points Operations: Outside the continuation: start/restart the continuation • continuation.run() Inside the continuation: jump back to the caller • Continuation.yield(scope)
address space – Lightweight Lock • no context switch but – Thread stack is pre-allocated (=> OOM if a lot of threads) – Thread scheduling is done by the OS !
in fields even if the method call is not suspended – Can be improved ?? Generate a lot of bytecodes Can be improved at bit Kotlinc uses javac as back-end => lot of checkcasts
frames back main f2 heap stack bang! The VM tries to guess how many stack frames should be moved A read of the stack bang trigger the copy of the remaining frames
System.out.println("server bound to " + server.getLocalAddress()); var remote = SocketChannel.open(); remote.connect(new InetSocketAddress(InetAddress.getByName(Host.NAME), 7)); System.out.println("accepting ..."); var client = server.accept(); new Thread(runnable(client, remote)).start(); new Thread(runnable(remote, client)).start();
the continuation – All blocking calls do internally a yield – The JDK code calls run() on the continuation when it can be rescheduled All the JDK needs to be patched to be “fiber aware”
a native frame on the stack Fiber – Yielding inside a synchronized block pins the fiber to that thread • The same thread as to be used when re-scheduling • This limitation may be removed in the future
Bytecode bloat (parts can be improved) but Fast ! – Split world, “suspended” or not Java Loom – requires a new VM – No fat but not fast (yet ?) – One world