Automatically convert Thread to Fiber

[Lei Yu]

Hi,

Based on our try of the Fiber API and experience with Wisp(similar to loom, lightweight concurrency construct implemented in Alibaba JDK, widely used internally),  in addition to using explicit Fiber API, If we can consider automatically converting all normal Java threads as fibers ? 

The reasons come from:

1) New API is not free lunch for many existing libraries, need more code change efforts.
You can use fibers in the Servlet containers to to handle the web requests. The desirable way is to replace the normal ThreadPoolExecutor with FiberScope.background()::schedule by Servlet container's API or configuration.

However, for Tomcat as typical example,  which has been widely, heavily used in Java web servers,  we can not simply do this via configuration.

Even the users can do such code change in Tomcat to use fiber  ,  there is also some disadvantages. The intrinsic characteristics of ThreadPoolExecutor, e.g. poolSize, queuing behavior may have impact on the the application's behavior, such as limiting max number of concurrent requests. Directly replacing it with fiber for each request might result in losing such control. Ideally, the approach is to respect the these intrinsic characteristics imposed by ThreadPoolExecutor's and meanwhile, the underlying workers are created/run as fiber.

Moreover, many third-party libraries usually create a lot of threads internally, for example in some of our production cases, the max number of threads per application might be more than 1000. We also expect that these threads can also be replaced by fibers to save resources. 

2) Interaction overhead  between Fiber and Thread

Most of the distributed Java middleware are based on Netty. One of common usages is when the business thread needs doing RPC, it just delegates to Netty IO thread to handle request/response. When the response is coming in, the Netty IO thread wakes up the business thread which is waiting on Future to continue processing that response.

The fact that if we just only convert the business thread as fiber, the Netty IO thread is still running as normal thread might discount performance benefits gained from lightweight scheduling - The fibers are scheduled by ForkJoinPool, however the ForkJoinPool itself and Netty IO thread are scheduled by the OS.


By the way, actually Thread as Fiber feature has been implemented in Alibaba JDK, widely used in our e-commerce application. 

I was wondering if anyone is interested in this? not sure if anyone had started to work on this...
If not, I'll volunteer to propose a design...

Lei