On Fri, 9 Jul 2021 15:01:15 GMT, Maurizio Cimadamore <mcimadam...@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
