First (and most important) be sure you follow the Eclipse Legal / IP-Validation requirements.
You currently do not have an Eclipse ECA on file at Eclipse, nor have you follow the Developer Certificate of Origin requirement to "sign off" the git commit.
https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/CONTRIBUTING.md#eclipse-contributor-agreement
We'll need both of those addressed before we can accept this PR.

The java 8 .parallelStream() method uses the ForkJoinPool.commonPool() to spawn threads to handle this parallel processing.
This is undesired on a server platform, as those extra threads are not being handled by the server managed thread pools.
However, since this PR is limited to just jetty-start the impact should be negligible.

@joakime Thanks for the prompt feedback. AFAIK, I have signed the agreement; it seems that the validation server is down. But, I did forget to sign my commits. I'll do that now.

Using parallelStream() is only for exceptional cases.

Here we are on a server (not a good place to use parallelStream()) and we are iterating on streams that contain 10s or at most 100s elements (again not a good parallelStream() case).

Rule of thumb shared by most experts about parallelStream() is that you need at least 10k elements to win the parallel setup overhead.

@khatchad IIUC your benchmarks have been done with 1 million elements to show those gains.
Do you have gains for 10 and 100 elements only?

@joakime I signed my commits retroactively but doing so after a push doesn't seem to change the old commits. I guess I'll need to open a new PR. Sorry about that.

@sbordet I don't. Indeed, 1 million is the best gains I've seen in the literature. I'll run my script with 10 and 100 to see how it looks.

Superseded by #2838.

I am not keen for Jetty as a server to use things like parallelStreams. The use of parallelism is really good if you have a single big task to do and wish to use all the CPUs available to achieve that in minimum time.
However, that is not the job of a server, which has many many tasks to do and the most important thing to optimize is the number of tasks completed rather than the elapsed time of any particular task.

Specifically, the last thing we want to do for any task that originates from a single connection/request, is to spread it's handling over all the CPUs of a server, filling all the caches with data from/for that single request. It is far FAR better that each CPU and its caches is dedicated to tasks from individual requests for as long as possible, allowing other CPUs to work on other requests with minimal (if any) contention. We actually go to some lengths in our scheduler to achieve this.

So thanks for the contribution, but it's not a direction we wish to follow.

@gregw Thank you for the feedback!

@sbordet:

@khatchad IIUC your benchmarks have been done with 1 million elements to show those gains.
Do you have gains for 10 and 100 elements only?

It would seem that 10 and 100 elements is not enough to overcome the overhead. Please see below. The left is the original and the right is the refactored version:

156,160c160,164
< Benchmark                                    (N)  Mode  Cnt   Score    Error  Units
< AbstractDocumentTest.shouldRetrieveChildren   10  avgt    5  ≈ 10⁻⁴           ms/op
< AbstractDocumentTest.shouldRetrieveChildren  100  avgt    5   0.001 ±  0.001  ms/op
< DomainTest.shouldConstructCar                 10  avgt    5  ≈ 10⁻⁴           ms/op
< DomainTest.shouldConstructCar                100  avgt    5   0.001 ±  0.001  ms/op
---
> Benchmark                                    (N)  Mode  Cnt  Score   Error  Units
> AbstractDocumentTest.shouldRetrieveChildren   10  avgt    5  0.043 ± 0.022  ms/op
> AbstractDocumentTest.shouldRetrieveChildren  100  avgt    5  0.293 ± 0.027  ms/op
> DomainTest.shouldConstructCar                 10  avgt    5  0.045 ± 0.009  ms/op
> DomainTest.shouldConstructCar                100  avgt    5  0.280 ± 0.026  ms/op