Questions about QCon'19 London talk

[Ron Pressler]

On 5 December 2019 at 12:06:47, Volkan Yazıcı (volkan.yazici at gmail.com(mailto:volkan.yazici at gmail.com)) wrote:

> Hello,  
>  
> I have some questions regarding Ron's QCon'19 London talk titled "Why  
> Continuations are coming to Java?"  
> . I will be appreciated if you  
> can spare some time to help me figuring them out.  
>  
> *1.* In the talk, Ron states that the team considers implementing  
> Serializable in Continuation class. There it is further shared that the  
> continuation might even get resumed on a different physical machine than  
> the one it was suspended from. Given a majority of the continuation-related  
> marketing pitches are surrounded around I/O, how do you plan to preserve  
> the stateful nature of the I/O resources (e.g., a network socket) while  
> migrating a continuation bound to that resource from one machine to another?  



That will be up to application code — just as with serialization today.

>  
>  
> *2.* In the structured concurrency example, that is, anyOf() method, why  
> don't we just replace the entire "try { } catch (...) {  
> ... } finally { }" with just ""?  
> Isn't the purpose of "" already served by  
> try-with-resources on FiberScope?  
>  

Well, for one, the entire structured concurrency API is very much in flux,  
so much so that it doesn’t exist in the current prototype at all. But in the  
API presented, the implicit call to close() in the TWR block waits for the
completion of all threads; it does not attempt to cancel them.

> *3.* I see that the Continuation provides a getStackTrace() method. Is it  
> gonna get cloned ala Throwable#getStackTrace()? A gc-free getStackTrace()  
> would particularly be useful for certain logics that strive for a gc-free  
> runtime, e.g., loggers. Would you mind sharing some comments on this,  
> please? Is it technically feasible? If not, why?  

Continuation will likely not be public, at least at first, so this is for internal 
JDK use, but there are two mechanisms for getting the stack trace. Either with 
getStackTrace, which allocates a StackTraceElement array, or with stackWalker()
that uses the StackWalker API.

As an aside, I should point out that avoiding allocations is not the same
as avoiding GC overhead when concurrent GCs, which are now the default, are used.
In fact, zealously avoiding all allocations may result in an *increase* to GC 
overhead. The only way to avoid any interaction with the GC is to never use 
any objects at all, only static methods and primitives.

- Ron



>  
>  
> Thanks in advance.  
>  
> Best regards.