JCP meeting(s) at JavaOne this year

Sun May 31 20:12:19 PDT 2009

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>
Date: May 26, 2009 11:23:03 PM PDT
To: Java Community Process JSR #292 Expert List <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090531/e42f479a/attachment.html 