My experience using loom for a load generator

[Eric Ackermann]

Good evening,

>If you can run the hs_err file then it might be useful.

It seems that I forgot to attach it to the last email, I will make sure to attach
it to this one.

>It would also be 
>useful if you could do a run with -XX:-UseContinuationChunks to see if 
>it duplicates (this option uses the older implementation and knowing if 
>it happens with that option might narrow down the issue

I ran my complete unit test suite with -XX:-UseContinuationChunks 5 times, 
and it did not crash once. I removed the option, and it immediately crashed.
So the crashes seem to be related to this algorithm.

>If you have time, it would be useful if you could summarize what happens 
>in these threads. My guess is that they are only blocking once or twice 
>(in Future::get). Would I be correct to say that most of the work is 
>done on the threads in the Netty thread pool rather than on the virtual 
>threads?

Users can specify the behaviour of each thread. A number of options that require
more or less computation are available, and how much computation is required
also depends on the received response. For example, threads might run XPATH 
queries on responses. Also, the number of requests each thread sends can be 
configured. I experienced crashes both with 1 and 100 requests per thread 
being sent.
Generally speaking, threads supply data to the requests that Netty will process and
evaluate responses that Netty retrieved.
In the scenario for which I compared the performance, almost all work is done by 
the Netty thread pool. In my suite of unit tests, all features are evaluated for 
small examples at some point. Both crashed while testing. The unit test suite 
always crashed during one of the scenarios in which most work was done by Netty,
however.

I hope this helps.

Kind regards,

Eric Ackermann