[12] RFR(S): 8177899: Tests fail due to code cache exhaustion on machines with many cores

[Doerr, Martin]

Hi Tobias,

> Well it's just an upper limit and the number of compiler threads that are actually created should be
> controlled by -XX:+UseDynamicNumberOfCompilerThreads.
I know, but it looks like a complicated computation for a simple task which is difficult to maintain if the other code changes.
As you have written, it can happen that the threads really get started and I don't see any benefit of starting so many threads that most of them can never generate a nmethod because it simply wouldn't fit.
Anyway, your change seems to fix the issue and if other reviewers like it this way, ok.

> I think the heuristic should be improved to
> consider the available space in the code cache as well (not only the available memory). Since the
> available space in the code cache depends on many factors, I don't think a constant is feasible. I
> would prefer to file a RFE for that.
That sounds like a good idea, too.

> While looking at the computation again, I've noticed that JDK-8209594 increased the buffer size.
> I've updated C2Compiler::initial_code_buffer_size() accordingly:
> http://cr.openjdk.java.net/~thartmann/8177899/webrev.02/
Thanks for updating. Looks correct. I think this function could be used in compile.cpp, now to avoid code duplication.

Best regards,
Martin