Hey, I'm game to use the room/time as a refuge from the day-to-day grind of JavaOne. And we can sit and trade 292 patches back and forth if there's no discussion to be had.
John Rose wrote: > On May 31, 2009, at 5:09 PM, Charles Oliver Nutter wrote: > >> Did any meeting times get settled? Especially ones that non-EG members >> could be at to discuss things? > > Yes. The message below represents my current reservations, plus the > list of current issues. > > Unfortunately, the IBM J9 guys are busy in all three time slots, so we > may add a fourth. > > But I intend to use at least two of the three slots below to meet with > JSR 292 stakeholders, even if it is just me and one other person in the > room. > > More details later... > > -- John > > Begin forwarded message: > > *From: *John Rose <[email protected] <mailto:[email protected]>> > *Date: *May 26, 2009 11:23:03 PM PDT > *To: *Java Community Process JSR #292 Expert List <[email protected] > <mailto:[email protected]>> > *Subject: **JSR 292 issue list & JavaOne meet-up* > > Hello EG members. Here is an issue list I have been keeping. Please > send additional issues to me. > > The issues marked resolved are the major changes from last year's EDR. > > If you have additional insight into any issue, especially if it would > tend to change the resolution from the default resolution, please let us > know. > > I would like to discuss these issues face to face at JavaOne. I have > reserved the JCP room for the following three time slots: > > June 3, 2009 from 9:00 AM to 11:00 AM > June 4, 2009 from 12:00 PM to 2:00 PM > June 5, 2009 from 1:00 PM to 3:00 PM > > The room is the Nob Hill room on the 4th floor of the Intercontinental > Hotel in San Francisco. > The Intercontinental is located at 888 Howard Street, one block away > form the Moscone center. > http://www.intercontinentalsanfrancisco.com/welcome.php > > -- John > > > JSR 292 Issue List > > --- structure of reified call sites > > ISSUE CALL-SITE-IDENTITY: Shall CallSite have (a) a stable reference > identity for the lifetime of the invokedynamic instructions, or (b) an > implementation-dependent reference identity? (Default answer: (a).) > > ISSUE CALL-SITE-EQUALS: Shall CallSite.equals be (a) reference > identity, (b) target identity, and/or (c) a structural equality > comparison on a known set of public attributes (such as name)? (Default > answer: (b) and, given CALL-SITE-IDENTITY/a, (a).) > > ISSUE CALL-SITE-LOCATION-ID: Shall CallSite have attributes to identify > the method and BCI in which the call occurs? > > ISSUE CALL-SITE-INSTANCE-ID: If CALL-SITE-CLONING/yes, shall CallSite > have an instance number to distinguish clones? (Default answer: no.) > > ISSUE CALL-SITE-CONSTRUCTOR-ARGUMENTS: Shall the CallSite constructor > (and the signature of the factory method which creates call site) > include information about the identity of the method and BCI at which > the call site occurs? (Default answer: no.) > jrose: The cost of doing this is probably small, and benefit may be > significant for some apps. > > ISSUE CALL-SITE-SPLITTING: Shall the JVM be allowed to split an > invokedynamic instructions into two or more targets and CallSite > objects? (E.g., it could opt to split out an inlined copy of a call > site.) (Default answer: yes; synergizes with JVM-specific inlining > tactics.) > > RESOLVED-ISSUE CALL-SITE-SUBCLASS: Shall invokedynamic call sites be > reified by a user-defined subclass of CallSite? Answer: Yes, via the > BSM which serves as a factory for them. The choice of subclassing is > the responsibility of the BSM. > > --- method handle construction > > RESOLVED-ISSUE ACCESS-CHECK-FACTORED: Shall factory methods which > perform access checks (a) always inspect the stack to determine the > caller, or (b) run within a capability object whose constructor can > inspect the stack? Answer: (b). > > RESOLVED-ISSUE SELF-BOUND-MH: Shall we supply an abstract super-class > for deriving user-defined method handle types? Answer: yes, it's easy > given bound method handles, and they have proven extremely useful in > practice. > > ISSUE METHOD-HANDLE-FIND-EXCEPTIONS: Shall we have the find* methods > throw checked exceptions for failed lookups and/or failed accesses, and > what are the details? (Default answer: yes; this is the Java Way.) > > ISSUE METHOD-HANDLE-CONVERSIONS: Shall we allow an implicit > convertArguments step at a MH.invoke site, if the caller and callee > disagree about the call type, but do agree on number of arguments? > (Default answer: no, implementation complexity and performance potholes.) > ohrstrom: See > http://blogs.oracle.com/ohrstrom/2009/05/the_jsr292_endgame.html . > > --- other > > RESOLVED-ISSUE INSTRUCTION-FORMAT: Shall the invokedynamic instruction > be (a) an overloading of invokeinterface or (b) a new code point (186) > containing a CONSTANT_NameAndType reference? Answer: (b). > > ISSUE INSTRUCTION-PADDING: The invokedynamic instruction needs to be 5 > bytes long (for some JVM implementations, to allow embedded coding of > call site identity). GIven that, shall the final two bytes be (a) > required to be zero and reserved for future use, or (b) used for some > present use? (Default answer: (a). No credible use is known at present.) > > RESOLVED-ISSUE BOOTSTRAP-CALL-COMPLETION: Should the bootstrap method > of an invokedynamic site (a) be passed caller arguments and required to > complete the call, or (b) be required only to return the target, which > would then be used even for the first, linking, invocation? Answer: > (b), changed from (a). > jrose: This greatly simplifies the support for an invokedynamic site, > without loss of generality. > > ISSUE LANGUAGE-SUPPORT-CHECKED-EXCEPTIONS: In the Java language support, > shall we have the implicit methods of MH.invoke and InDy.* throw > Exceptions, to force checked exception processing at all call sites to > method handles? > Comment: The language people know there are loopholes, e.g., in > Class.newInstance, but they don't want any more. > > ISSUE PUSH-INVALIDATION-NEEDED: Do we need a way of resetting call > sites that is serialized with their execution? (Default answer: yes.) > > ISSUE METHOD-HANDLE-CONSTANTS: Shall we extend ldc to provide direct > access (via constant pools) to direct method handles via the previously > unused CONSTANT_Xref constant pool types, as an alternative to the > Lookup.find* methods (when the operands are compile-time literals)? > > ISSUE METHOD-TYPE-CONSTANTS: Shall we extend ldc to provide direct > access (via constant pools) to method types via the previously unused > CONSTANT_Utf8 constant pool type, as an alternative to MethodType.make > (when the operands are compile-time literals)? > > --- open-ended (or vaguely formulated) issues: > > ISSUE METHOD-HANDLE-CONSTRUCTORS: Is the set of method handle > constructors in java.dyn.MethodHandles sufficient, useful, and simple > enough to implement? (Default answer: Yes.) > See also METHOD-HANDLE-CONVERSIONS. > _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
