[HN Gopher] On Java/JVM: Loom and Thread Fairness
       ___________________________________________________________________
        
       On Java/JVM: Loom and Thread Fairness
        
       Author : lichtenberger
       Score  : 31 points
       Date   : 2022-06-02 20:24 UTC (2 hours ago)
        
 (HTM) web link (www.morling.dev)
 (TXT) w3m dump (www.morling.dev)
        
       | klabb3 wrote:
       | I only observe Java from a distance but everything I've read
       | about project loom is amazing.
       | 
       | Speaking as someone who has worked intricately on an async
       | runtime in another language, I've more and more started to
       | question the premises around the explicitly async paradigm. Lots
       | of things we were "promised" with async turned out to be just as
       | complicated in the threaded (i.e. blocking) programming models,
       | and now we have two incompatible programming models. I'm now of
       | the opinion that we should improve (instead of replace) our
       | threaded models and do under-the-hood optimizations to sort out
       | the performance issues.
       | 
       | If I had a dime for everytime someone made a blocking call from
       | an async function.. And who can blame them? Most blocking
       | functions aren't even documented as such, you just have to know.
        
         | lichtenberger wrote:
         | Yes, I think Loom is an amazing step forward and it's brilliant
         | to just change the blocking methods and thus existing code
         | might already benefit with minor changes.
        
       | lichtenberger wrote:
       | The mentioned twitter discussion is also pretty interesting IMHO
       | :-)
        
       | BenoitP wrote:
       | Not a new kind of issue, and not a problem IMHO.
       | 
       | Some GCs need to reach a safepoint before doing their work; and
       | when a classic Thread is chugging along in a tight loop, that
       | thread is blocking the whole system for a pending GC.
       | 
       | One hacky fix is to provide an opportunity for a safepoint
       | (System.out.print every 10k iterations). Other tools like JVM
       | command line options allow for observing safepoint triggering.
       | 
       | The same goes for virtual threads: inserting a Thread.sleep(1L)
       | every nth iteration of a tight loop does it.
       | 
       | Also there was talk specifying a custom scheduler for the virtual
       | threads. That would not help in inserting switching
       | opportunities, but it would give a way to define what kind of
       | fairness you want.
        
       ___________________________________________________________________
       (page generated 2022-06-02 23:01 UTC)