JCP meeting(s) at JavaOne this year

[Charles Oliver Nutter]

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 <john.rose at sun.com <mailto:john.rose at sun.com>>
> *Date: *May 26, 2009 11:23:03 PM PDT
> *To: *Java Community Process JSR #292 Expert List <JSR-292-EG at JCP.ORG 
> <mailto:JSR-292-EG at JCP.ORG>>
> *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.
>