问题标签 [invokedynamic]

是否有估计说明 JSR-292 会对 Groovy 性能产生多大影响？

我渴望开始在 Java 之上使用动态语言。

在这成为标准 JDK 的一部分之前多久？

Rich Hickey 和其他人提到 Clojure 不会从即将推出invokeDynamic的 JVM 7 或 8 计划中获得显着改进，但会从尾递归中看到性能提升。

尾递归是否会影响

或者

我不希望它们变得更快，因为编译器可能已经生成了循环结构。

我不断听到有关添加到 JVM 中的所有新酷特性，其中一个很酷的特性是 invokedynamic。我想知道它是什么以及它如何使 Java 中的反射编程更容易或更好？

JDK 7 的预发布版本包含一个类 java.dyn.InvokeDynamic，它允许从源代码创建调用动态指令。

见这里： http: //fwierzbicki.blogspot.com/2009/08/invokedynamic-and-jython-part-i.html

在正式的 JDK 7 版本中，这个类似乎已经消失了。有谁知道这个源代码选项是否仍然受支持？

正如我从阅读这篇关于 JDK 7 中新的 invokedynamic 字节码指令的帖子中了解到的那样，它可以调用对象类中未静态定义的对象上的方法，并将这些方法调用解析为某些具体的静态方法其他类通过拦截方法调用目标解析（帖子给出了例子）。

这是否意味着 Java 7 类可以拥有像 Scala 那样的隐式方法？如果不是，Scala 中的隐式方法解析与调用动态方法解析有何不同？

我正在尝试invokedynamic在 JVM7 中实现“鸭子打字”。我创建了两个不同的类，它们都有greet()返回的方法String。我在其中一个之间随机选择，将实例存储在堆栈上并调用invokedynamic（使用 ASM）。

我想知道我是否可以在引导方法中访问参数。因为我不能在不知道堆栈上的对象以及应该返回哪些方法的情况下返回CallSite适当的target。greet()

如果我的方法是错误的，那么正确的方法是什么？

类描述中显示的示例在调用具有以下描述的语句时MethodHandle抛出 a ： 。WrongMethodTypeExceptionmh.invokeExact("daddy",'d','n')(CC)Ljava/lang/String; cannot be called with a different arity as ([Ljava/lang/Object;)Ljava/lang/Object;

该MethodHandle对象mh有一个符号类型描述符，对应于：(CC)Ljava/lang/String。但是当我们调用时mh.invokeExact("daddy",'d','n')，参数：d和n作为Object数组传递，然后它们与类型的参数不匹配char。

我知道我可以使用invokeWithArguments代替invokeExcat或来解决上述问题，但是这个示例应该按照Java 7 APIinvoke的描述中的说明工作。MethodHandle除此之外，与/invokeWithArguments相关的性能开销。invokeinvokeExact

我正在研究 JDK 1.7 的新功能，但我无法理解 MethodHandle 的设计用途？我理解（直接）调用静态方法（以及在这种情况下直接使用核心反射 API）。我也理解（直接）调用虚拟方法（非静态，非最终）（以及使用需要通过类的层次结构的核心反射 API obj.getClass().getSuperclass()）。非虚方法的调用可以视为前者的特例。

是的，我知道超载存在问题。如果要调用方法，则必须提供确切的签名。您不能以简单的方式检查重载方法。

但是，MethodHandle 是关于什么的？反射 API 允许您“查看”对象内部而无需任何预先假设（如实现接口）。您可以出于某种目的检查对象。但是 MethodHandle 又是怎样设计的呢？为什么以及何时应该使用它？

更新：我现在正在阅读这篇http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html文章。据它说，主要目标是简化运行在 JVM 之上的脚本语言的生活，而不是简化 Java 语言本身的生活。

UPDATE-2：我读完上面的链接，从那里引用一些：

JVM 将成为构建动态语言的最佳 VM，因为它已经是动态语言 VM。InvokeDynamic 通过向一流的 JVM 公民推广动态语言，将证明这一点。

使用反射来调用方法效果很好......除了一些问题。方法对象必须从特定类型中检索，不能以一般方式创建。<...>

...反射调用比直接调用慢很多。多年来，JVM 在快速实现反射调用方面做得非常好。现代 JVM 实际上会在幕后生成一堆代码，以避免旧 JVM 处理的大量开销。但简单的事实是，通过任意层数的反射访问总是比直接调用慢，部分原因是完全通用的“调用”方法必须检查并重新检查接收器类型、参数类型、可见性和其他细节，但是还因为参数必须都是对象（因此原语被对象装箱）并且必须作为数组提供以涵盖所有可能的参数（因此参数被装箱）。

对于执行一些反射调用的库来说，性能差异可能并不重要，特别是如果这些调用主要是在内存中动态设置一个静态结构，它可以对其进行正常调用。但是在动态语言中，每次调用都必须使用这些机制，这会严重影响性能。

http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html

因此，对于 Java 程序员来说，它本质上是无用的。我对吗？从这个角度来看，它只能被认为是Core Reflection API的替代方式。

UPDATE-2020：确实，MethodHandle 可以被认为是核心反射 API 的更强大的替代方案。从 JDK 8 开始，还有一些使用它的 Java 语言特性。

最近，我正在阅读有关 Java 7 特性的信息，invokedynamic 是最受期待的特性之一。大多数博客/文章从 JVM 实现的角度提供了优势，特别是对于动态类型语言。从应用程序开发人员的角度来看，它对我有何影响？