DinnerAtPiatti - Revision history

Forax: /* Constant Pool Constants */

2009-09-26T14:07:16Z

‎Constant Pool Constants

Forax at 14:03, 26 September 2009

2009-09-26T14:03:11Z

Jrose at 01:48, 25 September 2009

2009-09-25T01:48:48Z

Jrose at 00:22, 25 September 2009

2009-09-25T00:22:16Z

Jrose at 00:17, 25 September 2009

2009-09-25T00:17:35Z

Jrose at 22:05, 24 September 2009

2009-09-24T22:05:39Z

Jrose: New page: Friday night after the Summit, some of us who hadn't had enough yet went across the street to Piatti for dinner. Emboldened by good food and drink, some of the JSR 292 EG members (Forax, ...

2009-09-24T21:30:06Z

New page: Friday night after the Summit, some of us who hadn't had enough yet went across the street to Piatti for dinner. Emboldened by good food and drink, some of the JSR 292 EG members (Forax, ...

New page

Friday night after the Summit, some of us who hadn't had enough yet went across the street to Piatti for dinner.

Emboldened by good food and drink, some of the JSR 292 EG members (Forax, Ohrstrom, Rose, ...) worked on some hard remaining issues. Here are the napkins to prove it.

[[Media:FridayDinnerNapkin1.jpg]] [[Media:FridayDinnerNapkin2.jpg]] [[Media:FridayDinnerNapkin3.jpg]] [[Media:FridayDinnerNapkin4.jpg]]

← Older revision		Revision as of 14:07, 26 September 2009
Line 155:		Line 155:

	Also LDC instruction spec should be changed to allow CONSTANT_MethodHandle_info and CONSTANT_MethodType_info.		Also LDC instruction spec should be changed to allow CONSTANT_MethodHandle_info and CONSTANT_MethodType_info.
		+	About the runtime semantics,
		+	LDC CONSTANT_MethodType_info == LDC CONSTANT_MethodType_info is required to return true
		+	if the constant values are equals.
		+	The same is not true with LDC CONSTANT_MethodHandle_info.

	Advantages to using constant pool:		Advantages to using constant pool:

@@ Line 129: / Line 129: @@
 ==== Constant Pool Constants ====
-Should be for MT and four kinds of MH:  virtual/interface, static, special.
+Should be for MethodType and four kinds of MH:  virtual/interface, static, special.
-Idea:  Have the constant pool format for CONSTANT_MethodHandle be parameterized by (a) a member reference, and (b) a bytecode point (invokespecial, etc.).  Makes clear the correspondence between the symbolic reference and the semantics of the resulting method handle.  This also extends naturally to all other symbolic references:
+Idea:  Have the constant pool format for CONSTANT_MethodHandle_info be parameterized by (a) a member reference, and (b) a bytecode point (invokespecial, etc.).  Makes clear the correspondence between the symbolic reference and the semantics of the resulting method handle.  This also extends naturally to all other symbolic references:
 * invokevirtual, CONSTANT_Methodref = findVirtual (must be class)
 * invokeinterface, CONSTANT_InterfaceMethodref = findVirtual (must be interface)
@@ Line 140: / Line 140: @@
 * putfield, CONSTANT_Fieldref = unreflectSetter (must be non-static)
 * putstatic, CONSTANT_Fieldref = unreflectSetter (must be static)
 Advantages to using constant pool:

← Older revision		Revision as of 01:48, 25 September 2009
Line 172:		Line 172:

	The problem gets a little more complex if argument or return types are replaced arbitrarily; for example <tt>int Foo.equals(boolean)</tt> overriding <tt>boolean Object.equals(Object)</tt>.		The problem gets a little more complex if argument or return types are replaced arbitrarily; for example <tt>int Foo.equals(boolean)</tt> overriding <tt>boolean Object.equals(Object)</tt>.
		+
		+	==== Invalidation ====
		+	Dynamic languages can reverse themselves: The meaning of a call site can change over time due to changes in the runtime, especially in the application's type schema.
		+
		+	Groovy currently gets a serious performance hit from polling a schema evolution counter on each method call. This counter is volatile, to make sure it updates to every thread. This is a typical "pull" or "polling" type of invalidation logic.
		+
		+	JSR 292 will include "push" invalidation.
		+
		+	Call site states, excluding invalidation:
		+	* not yet executed
		+	* executed, but bootstrap method not yet returned
		+	* linked: reified as a unique call site (returned from BSM)
		+	* relinked: <tt>CallSite.setTarget</tt> can be called any number of times
		+
		+	Note that <tt>CS.setTarget</tt> does not have volatile semantics. Threads may take any amount of time to witness changes. This is by design.
		+
		+	Key question: How do we (a) back up to a known state, (b) forcing all threads to see the change, (c) without race conditions, and (d) without per-call polling? Answer: Collect call sites for invalidation, and bulk-invalidate at a well-defined safepoint.
		+
		+	(Why bulk? Because most implementations will be too slow for piecemeal work; need big transactions.)
		+
		+	The JVM (at least, Hotspot) has subtle mechanisms for this, to perform revirtualization when a devirtualized call site becomes invalid, due to class loading (class schema change). After some discussion, it was agreed that GCs in general require such global critical sections too.
		+
		+	The answer we came up with is "full back-out at a safepoint". Details:
		+	* The runtime (language or application) initiates any global transaction it wants
		+	* The runtime marks the CallSite it wants to invalidated (and any other sites as well)
		+	* The runtime requests bulk invalidation from the JVM
		+	* The JVM invalidates the CallSite in a global critical section ("safepoint")
		+	* During this safepoint, every affected invokedynamic instruction is either blocked or has rolled forward
		+	* The CallSite object is discarded (collectable by GC)
		+	* The invokedynamic instruction is backed up to a "not yet executed" state
		+	* As soon as the JVM returns, threads may execute the invokedynamic instruction, triggering its BSM
		+	* The BSM interacts correctly with the runtime's current transaction
		+
		+	Backing all the way out to an unlinked state is cleanest. Alternative: Back up to a "known initial target value" on the call site. Seems to require messy bytecode execution in uncontrolled contexts, to compute and store the initial target value.
		+
		+	Implications of full back-out:
		+	* BSM can return the same call site as last time, if desired (''only if'' we supply an "is-live" query)
		+	* gives a "hook" for changing the class and/or identity of a call site
		+	* 1-to-many bytecode-to-CS relation meshes nicely with call site splitting (which Remy has rightly insisted on)
		+
		+	This design allows threads to run invokedynamic instructions with complete concurrency except during specified global safepoints.
		+
		+	Remaining problem: Define what it means to "roll forward" through an invokedynamic call. Should execute the whole call site target entry including pre-entry adapters, including argument boxing, etc. Can define this w.r.t. the functions in MHs, but this adds a funny privilege to them. This could interact with tail-call guarantees.

@@ Line 67: / Line 67: @@
 Spreading and collecting are of course interrelated:
-{|
+{| border="1"
-!!          !! spreading from av to mh(x,y) !! collecting from (x,y) to mh(av)
+!          !! spreading from av to mh(x,y) !! collecting from (x,y) to mh(av)
-|| call     || mh.varargsInvoke(av)    || mh.exactInvoke(new Object[]{x,y})
+|-
-|| adapt    || mh.spreadArgumments()   || mh.collectArguments(2)
+| call     || mh.varargsInvoke(av)    || mh.exactInvoke(new Object[]{x,y})
 |}

@@ Line 1: / Line 1: @@
 Friday night after the Summit, some of us who hadn't had enough yet went across the street to Piatti for dinner.
-Emboldened by good food and drink, some of the JSR 292 EG members (Forax, Ohrstrom, Rose, ...) worked on some hard remaining issues.  Here are the napkins to prove it.
+Emboldened by good food and drink, some of the JSR 292 EG members and others (Forax, Ohrstrom, Szegedi, Bini, Rose, ...) worked on some hard remaining issues.  Here are the napkins to prove it.
 {|
@@ Line 17: / Line 17: @@
    ? exactInvoke(?)
    ? genericInvoke(?)
+   ? varargsInvoke(Object...)  // maybe? does a spread
-   MH convertArgs(MT)
    MH bind(x)
-   MH spreadArguments()
+   MH spreadArguments()     // creates a spreader
-   MH collectArguments(int n)
+   MH collectArguments(int n) // creates a fixed-arity collector
    MH convertArgments(MT)
-   "MH collectVarargs()" (maybe?)
+   "MH collectVarargs()" // maybe?  creates a variable-arity collector
    toString() ??
@@ Line 31: / Line 32: @@
 </pre>
-Change <tt>insertArgument</tt> to <tt>bind</tt> or (per Ola) <tt>prependArgument</tt>.
+Rename <tt>MH.insertArgument</tt> to <tt>MH.bind</tt> or (per Ola) <tt>MH.prependArgument</tt>.
 ==== What should toString return? ====
@@ Line 37: / Line 41: @@
 * Implementation-dependent
 * Object.toString
-* Current RI:  The simple-name of the target method.  (For system-defined combinators, delegates to target.toString; user-defined ones also.)  SImple and useful.
+* Current RI:  The simple-name of the target method.  (For system-defined combinators, delegates to target.toString; user-defined ones also.)  Simple and useful.
 ==== Calling Sequences ====
@@ Line 53: / Line 89: @@
 call [ecx+edx]
 </pre>
 ==== Java Method Handles ====
@@ Line 75: / Line 138: @@
 * putfield, CONSTANT_Fieldref = unreflectSetter (must be non-static)
 * putstatic, CONSTANT_Fieldref = unreflectSetter (must be static)

← Older revision		Revision as of 22:05, 24 September 2009
Line 3:		Line 3:
	Emboldened by good food and drink, some of the JSR 292 EG members (Forax, Ohrstrom, Rose, ...) worked on some hard remaining issues. Here are the napkins to prove it.		Emboldened by good food and drink, some of the JSR 292 EG members (Forax, Ohrstrom, Rose, ...) worked on some hard remaining issues. Here are the napkins to prove it.

−	[[~~Media~~:FridayDinnerNapkin1.jpg]] [[~~Media~~:FridayDinnerNapkin2.jpg]] [[~~Media~~:FridayDinnerNapkin3.jpg]] [[~~Media~~:FridayDinnerNapkin4.jpg]]	+	{\|
		+	\|[[Image:FridayDinnerNapkin1.jpg\|160px\|thumb\|frameless]]
		+	\|[[Image:FridayDinnerNapkin2.jpg\|160px\|thumb\|frameless]]
		+	\|[[Image:FridayDinnerNapkin3.jpg\|160px\|thumb\|frameless]]
		+	\|[[Image:FridayDinnerNapkin4.jpg\|160px\|thumb\|frameless]]
		+	\|}
		+
		+	==== MethodHandle sub-kernel ====
		+
		+	<pre>
		+	class MH {
		+	MT type()
		+	? exactInvoke(?)
		+	? genericInvoke(?)
		+
		+	MH convertArgs(MT)
		+	MH bind(x)
		+	MH spreadArguments()
		+	MH collectArguments(int n)
		+
		+	MH convertArgments(MT)
		+
		+	"MH collectVarargs()" (maybe?)
		+
		+	toString() ??
		+	examine() ??
		+	</pre>
		+
		+	Change <tt>insertArgument</tt> to <tt>bind</tt> or (per Ola) <tt>prependArgument</tt>.
		+
		+	==== What should toString return? ====
		+	Simple answers:
		+	* Implementation-dependent
		+	* Object.toString
		+	* Current RI: The simple-name of the target method. (For system-defined combinators, delegates to target.toString; user-defined ones also.) SImple and useful.
		+
		+	==== Calling Sequences ====
		+
		+	MH.genericInvoke does autoboxing. Can result in an OOM error. The JVM can make the adapter non-blocking, by preallocating all the boxing memory in advance (in thread-local buffer) before advancing into the call. If the allocation fails, the call site is restarted after GC.
		+
		+	<pre>// virtual call through vtable:
		+	mov [obj] -> ecx
		+	call [ecx+off]
		+	</pre>
		+
		+	<pre>// mh call through vtable:
		+	mov [obj] -> ecx
		+	mov [obj+6] -> edx
		+	call [ecx+edx]
		+	</pre>
		+
		+	==== Java Method Handles ====
		+
		+	<pre>
		+	class Foo extends JavaMethodHandle {
		+	Foo() { super(#myInvoke); }
		+	void myInvoke() { ... }
		+	}
		+	</pre>
		+
		+	==== Constant Pool Constants ====
		+	Should be for MT and four kinds of MH: virtual/interface, static, special.
		+
		+	Idea: Have the constant pool format for CONSTANT_MethodHandle be parameterized by (a) a member reference, and (b) a bytecode point (invokespecial, etc.). Makes clear the correspondence between the symbolic reference and the semantics of the resulting method handle. This also extends naturally to all other symbolic references:
		+	* invokevirtual, CONSTANT_Methodref = findVirtual (must be class)
		+	* invokeinterface, CONSTANT_InterfaceMethodref = findVirtual (must be interface)
		+	* invokestatic, CONSTANT_Methodref = findStatic
		+	* invokespecial, CONSTANT_Methodref = findSpecial
		+	* getfield, CONSTANT_Fieldref = unreflectGetter (must be non-static)
		+	* getstatic, CONSTANT_Fieldref = unreflectGetter (must be static)
		+	* putfield, CONSTANT_Fieldref = unreflectSetter (must be non-static)
		+	* putstatic, CONSTANT_Fieldref = unreflectSetter (must be static)