JCP meeting(s) at JavaOne this year
Charles Oliver Nutter
charles.nutter at sun.com
Mon Jun 1 00:15:17 PDT 2009
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
> 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
> 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.
> -- 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
> 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
> 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.
More information about the mlvm-dev