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