initialization times for invokedynamic

[Claes Redestad]

Hi, 

Could you post the full benchmark code somewhere?

Which JDK version did you test this on?  Later JDKs will use a MH-backed solution under the covers but much of the overhead of early initialization is mitigated by various techniques (pre-generating some LambdaForms, caching some runtime generated code in CDS etc) so it’s important for context to get more details. 

Best regards
/Claes

> 4 sep. 2023 kl. 13:56 skrev Jochen Theodorou <blackdrag at gmx.org>:
> 
> Hi,
> 
> I write myself a small microbenchmark to get an idea about the time it
> takes to initialize a callsite. I made a simple test in which I write a
> class with a run method, which calls a method foo(I)I using
> invokedynamic and all the bootstrap method does is
> 
>> handle = caller.findStatic(IndyCallsiteTests.class, name, type);
>> return new ConstantCallSite(handle);
> 
> I compared this with a simple reflective solution:
> 
>>        Runnable r = new Runnable() {
>>            @Override
>>            public void run() {
>>               Method m = IndyCallsiteTests.class.getMethod("foo", int.class);
>>               m.invoke(null, 1);
>>            }
>>        };
> 
> and one with a very simple reflective caching:
> 
>>        Runnable r = new Runnable() {
>>            Method m = null;
>>            @Override
>>            public void run() {
>>                if (m == null) {
>>                    m = IndyCallsiteTests.class.getMethod("foo", int.class);
>>                }
>>                m.invoke(null, 1);
>>            }
>>        };
> 
> And my findings are that of course indy performs best in the long term,
> but based on reports I was wondering more about the initial costs. For
> the first couple of calls I get
> 
> reflectiveCallCached
> ------------------------------------
> 52627
> 8861
> 4335
> 3472
> 6032
> 6209
> 7484
> 7406
> 7267
> 6945
> 7546
> 7321
> 
> In sum ~122_000
> 
> reflectiveCall
> ------------------------------------
> 61720
> 20147
> 4916
> 3719
> 4723
> 3421
> 4839
> 4661
> 5428
> 4379
> 4615
> 4453
> 
> In sum ~127_000
> 
> indyCall
> ------------------------------------
> 835411
> 1461
> 1229
> 1335
> 1257
> 1500
> 1154
> 1546
> 1423
> 1351
> 1318
> 1303
> 
> In sum ~850_000
> 
> While peak performance is much better with indy, it takes a lot of calls
> (100k-200k) in this scenario for the indyCall to catch up to the other
> two variants.
> 
> I would like to know if others on this list have similar experiences. Or
> did I make a fundamental mistake?
> 
> bye Jochen
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.org
> https://mail.openjdk.org/mailman/listinfo/mlvm-dev