Hi Per! This is mostly invokedynamic related. Basically, an indy callsite requires a lot of implicit class and byte code generation, that is the source of the overhead we are mostly discussing. While tiered compilation adds non determinism, it is usually (IMHO) bearable…
/M On 23 Aug 2014, at 21:45, Per Bothner <p...@bothner.com> wrote: > > > On 08/23/2014 12:25 PM, Per Bothner wrote: >> On 08/22/2014 01:08 PM, Charles Oliver Nutter wrote: >>> What are the rest of you doing to deal with these issues? >> >> Start-up does not appear to a problem for Kawa: > > I should mention I'm not using invokedynamic, and have no > concrete plans to do so. However, I am working on pattern-matching, which > may make multi-methods more attractive, in which case invokedynamic > may be more of a benefit. InDy would probably also be helpful for arithmetic > (though for performance-critical code it is better to make use of > optional type specifiers and type inference) > > I will be using MethodHandles extensively in a re-write of the > "apply" mechanism that I'm working on. This will replace the "switch" > pattern I'm using, and should avoid the need for generating a 'ModuleBody' > class in some cases. > -- > --Per Bothner > p...@bothner.com http://per.bothner.com/ > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
