State of Loom

[Ron Pressler]

I meant the former, “obvious” reading. Because there are many more threads, 
the footprint impact of thread-local data is bigger.

— Ron


On 26 May 2020 at 13:10:36, Magnus Ihse Bursie (magnus.ihse.bursie at oracle.com) wrote:

Hi Ron,  

Thank you for a well-written presentation!  

I just reacted to the following statement: "ThreadLocals work for  
virtual threads, as they do for the OS-backed threads, but as they might  
drastically increase memory footprint". Could you possibly elaborate a  
bit on why this would be?  

What is "drastically" here? Do you mean that like "if you have a million  
threads, then you will have a million copies of the thread local data in  
question"? That sounds like a very obvious result of combining huge  
number of threads with thread local data. If you have a fantazillion  
number of threads, then of course you are going to need a fantazillion  
number of stack local variables, so reasonably you will also need a  
fantazillion number of thread local variables.  

Or do you mean that Loom will consume significantly *more* memory than  
N*sizeof(ThreadLocal data) for N threads? If so, why is that?  

/Magnus  

On 2020-05-15 16:55, Ron Pressler wrote:  
> Hello.  
>  
> I’ve posted a document describing the project’s goals and current progress:  
>  
>     http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html  
>  
> It is accompanied by a new EA build, based on jdk-15+21.  
>  
>     http://jdk.java.net/loom/  
>  
> The new continuations algorithm is now switched on by default, so if you haven’t  
> explicitly turned it on before, you may see some performance improvements.  
> You can switch it off with -XX:-UseContinuationChunks.  
>  
> — Ron  
>  
>  
>