hotspot-dvm

Code Review for hotspot-dvm

Prepared by:	jrose on Tue Jan 20 02:15:40 PST 2009
Workspace:	/Users/jrose/Projects/hotspot/hotspot-dvm
Compare against:	http://hg.openjdk.java.net/jdk7/hotspot-comp-gate/hotspot
Compare against version:	521
Summary of changes:	7334 lines changed: 7123 ins; 87 del; 124 mod; 100657 unchg
Patch of changes:	hotspot-dvm.patch
Author comments:	For putback to http://hg.openjdk.java.net/jdk7/hotspot-comp-gate/hotspot 6655638: dynamic languages need method handles Summary: first working version of method handles Reviewed-by: kvn This group of changes implements method handles, and is the second (and largest) in a series of three changes to support the JSR 292 Reference Implementation. A method handle is a lightweight and direct reference to a Java method. (It is a small wrapper around a methodOop in HotSpot.) It implements the method `java.dyn.MethodHandle.invoke`, for the exact signature of its Java method. That is, the `MethodHandle` type implements all possible signatures of the `invoke` method name. Invoking a method handle with the wrong signature safely produces a `WrongMethodTypeException`. There is as low-level API which privileged Java code uses to create and inspect method handles. All communication between the JVM and this Java code goes through native methods on the class `java.dyn.impl.MH`. Method handles can be formed which correspond to any of the standard "invoke***" instructions. A limited number of bound and adapter method handles are also supported, which allow types to be adjusted and closures to be created (as is necessary in dynamic languages). This change group builds on top of anonymous classes (project info) and lays the groundwork for the invokedynamic instruction (project info). module-by-module change summary The assembler changes let coders work more flexibly with values which may or may not be assembly-time constants. In particular, the RegisterConstant type is a trivial tagged union of a Register or an intptr_t constant, which selects the correct assembly instruction format automatically. New assembler macros factor code which used to be repeated in several places, for interface dispatch, type checking, and interpreter argument parsing. (Pre-existing copies of these are marked and left to be cleaned up later.) There are also macros for the two method handle operations: type checking and calling. Interpreter changes create a new kind of interpreter entry point for the `MethodHandle.invoke` methods; see `generate_method_handle_entry`. We also ensure (referring to `methodOopDesc::extra_stack`) that bound method handles have enough stack space to push an extra hidden argument (the bound receiver). There is also a new exception throwing stub, for `WrongMethodTypeException`s. A new module, "methodHandles.cpp", defines the new native method entry points. Its header file also defines the various subtypes of method handle (invokers and adapters), and creates a framework for both interpreted and compiled code to efficiently invoke method handles. (The compiled side of this framework is not implemented yet; compiled code presently uses C2I adapters to invoke method handles.) Each subtype of method handle has a distinct "handler" function, an assembled stub which executes that method handle's semantics, apart from the actual method being called. For example, an "invokevirtual" method handle looks up its target method in the vtable of its receiver, while a "checkcast" adapter performs a Java-level cast on one of its arguments, before permitting control to pass to the target method. The full set of handlers is generated by `generate_method_handle_stub`. The link resolver is extended with a notion of "implicit methods". When resolving an invokevirtual instruction, an `invoke` method on the type `java.dyn.MethodHandle` is constructed on the fly, once for each distinct signature. There is a new global table (a `SymbolPropertyTable`) which holds these methods; this table adds to the set of "strong" GC roots. The queries `is_method_handle_invoke` and `method_handle_type` apply to these new implicitly generated methods. The "method handle type" of such a method is a Java-level data structure of type `java.dyn.MethodType`, part of the JSR 292 API. There is a 1-1 correspondence between JVM signatures (symbolOops) and `MethodType` instances, as the corresponding invoke methods are created. An up-call to Java code obtains the `MethodType` object required for each new method handle invoker method. The set of built-in, well-known symbols, classes, and class layouts is extended as need (in the classfile subdirectory, files vmSymbols, systemDictionary, and javaClasses). There are occasional minor cleanups, such as the rewriting of old comments, deletion of dead code, or the improvement of debugging code. Currently, compiler changes are minimal. Method handle invocation sites are not candidates for inlining, and always go through C2I adapters. The Da Vinci Machine Project has been incubating this change as a patch named meth.patch. Along with this patch there are patches which create (as NetBeans projects) Java APIs on top of these JVM changes. See meth.proj.patch. These APIs are currently under review by the JSR 292 EG.
Legend:	Modified file Deleted file New file


 ------ ------ ------
 ------
 ---
New
Patch
Raw

src/cpu/sparc/vm/methodHandles_sparc.cpp


 ------ ------ ------
 ------
 ---
New
Patch
Raw

src/cpu/x86/vm/methodHandles_x86.cpp


 ------ ------ ------
 ------
 ---
New
Patch
Raw

src/share/vm/prims/methodHandles.cpp


 ------ ------ ------
 ------
 ---
New
Patch
Raw

src/share/vm/prims/methodHandles.hpp

This code review page was prepared using /Users/jrose/bin/hgwebrev (vers 23.12-hg-never).

Code Review for hotspot-dvm

module-by-module change summary