[jdk17] RFR: 8269281: java/foreign/Test{Down, Up}call.java time out

[Jorn Vernee]

On Fri, 9 Jul 2021 15:01:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> After some more investigation, I have been able to at least partially reproduce on my Linux box. While I can't get to same slowdown as we're seeing in test machines, I did notice that in fastdebug mode, TestUpcall is a lot slower than in release mode.
> 
> The underlying issue is that these tests are generating a lot of "throwaway" method handles. Method handles are typically stored in fields - when that happens, creating a method handle with same shape as one that has already been created typically works ok, w/o overhead, because there's a cache in the MethodType class which stores already generated lambda forms (by method handle kind). This cache is a SofteReference cahce, so, if the system is under memory pressure, the GC is of course free to null out all these cached values, in which case a new lambda form will be generated, and a new class will be loaded.
> 
> When looking at both TestDowncall and TestUpcall, in their current form, it is possible to observe a fairly large amount of classes being loaded and unloaded. Since the test generates many garbage, the GC is under pressure, and that causes entries in the lambda form cache to be evicted. The fact that one of the tests also explicitly calls out to `System::gc` doesn't help, and probably adds to the churn.
> 
> Since it is very hard, if not impossible, to fix the test so that all the required method handle are retained for the entire duration of the test (since we create different variations of same handles, based on the test being run), I believe the best solution would be to reduce the number of test combinations being executed.
> 
> This patch adds the ability to specify a sampling factor - which reduces the size of the test combinations being executed. Note that we also have a fuller test (which is never run automatically, but can be ran by hand: `TestMatrix`) - this test does not specify any sampling factor, so when developers run this stress test manually they will still run the whole shebang (which is what you want if you are tweaking the logic in the foreign support).

LGTM

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/238