On Apr 3, 2014, at 9:44 PM, John Rose john.r.r...@oracle.com wrote:
On Apr 3, 2014, at 6:33 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
Of course they are popular because these are the type names. There is no
type L; it’s an object. I don’t understand why we have
regards,
Vladimir Ivanov
On 3/26/14 12:24 AM, Christian Thalinger wrote:
+ enum BasicType {
+ L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types
+ I_TYPE('I', int.class,Wrapper.INT),
+ J_TYPE('J', long.class, Wrapper.LONG),
+ F_TYPE('F
regards,
Vladimir Ivanov
On 3/26/14 12:24 AM, Christian Thalinger wrote:
+ enum BasicType {
+ L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types
+ I_TYPE('I', int.class,Wrapper.INT),
+ J_TYPE('J', long.class, Wrapper.LONG),
+ F_TYPE('F
On Mar 24, 2014, at 1:33 PM, Igor Ignatyev igor.ignat...@oracle.com wrote:
Hi all,
Please review the patch:
Problems:
- MethodHandlesTest::testCatchException() doesn't provide enough testing of
j.l.i.MethodHandles::catchException().
- MethodHandlesTest contains more than 3k lines, an
On Mar 24, 2014, at 1:33 PM, Igor Ignatyev igor.ignat...@oracle.com wrote:
Hi all,
Please review the patch:
Problems:
- MethodHandlesTest::testCatchException() doesn't provide enough testing of
j.l.i.MethodHandles::catchException().
- MethodHandlesTest contains more than 3k lines, an
+ enum BasicType {
+ L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types
+ I_TYPE('I', int.class,Wrapper.INT),
+ J_TYPE('J', long.class, Wrapper.LONG),
+ F_TYPE('F', float.class, Wrapper.FLOAT),
+ D_TYPE('D', double.class,
On Mar 14, 2014, at 4:28 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8037210
953 lines changed: 425 ins; 217 del; 311 mod
This is a massive cleanup of JSR292 code to replace
On Mar 18, 2014, at 2:35 PM, John Rose john.r.r...@oracle.com wrote:
On Mar 18, 2014, at 1:36 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
Why are we not using an Enum instead of an untyped byte?
Byte is moderately typed, in the sense (which I rely on during development
?
There are no corresponding VM changes. The Object.clone hack is in the VM for
a very long time already.
-Rob
On 04/03/14 00:13, Christian Thalinger wrote:
On Mar 3, 2014, at 1:04 PM, Rob McKenna rob.mcke...@oracle.com wrote:
Hi Christian,
If you want to get this into 7u60 you'll need to add
On Mar 14, 2014, at 4:28 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8037210
953 lines changed: 425 ins; 217 del; 311 mod
This is a massive cleanup of JSR292 code to replace
On Mar 18, 2014, at 2:35 PM, John Rose john.r.r...@oracle.com wrote:
On Mar 18, 2014, at 1:36 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
Why are we not using an Enum instead of an untyped byte?
Byte is moderately typed, in the sense (which I rely on during development
,
Vladimir Ivanov
On 3/8/14 4:51 AM, Christian Thalinger wrote:
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target, Object...
args) throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov vladimir.x.iva
,
Vladimir Ivanov
On 3/8/14 4:51 AM, Christian Thalinger wrote:
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target, Object...
args) throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov vladimir.x.iva
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target, Object... args)
throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target, Object... args)
throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Looks good.
On Feb 25, 2014, at 12:43 PM, serguei.spit...@oracle.com wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1
Summary:
This is another Test
Looks good.
While touching the code some time ago John and I were playing around with the
idea to call Class.cast in the failing case:
+ static T,U T castReference(Class? extends T t, U x) {
+ // inlined Class.cast because we can't ForceInline it
+ if (x != null
On Feb 20, 2014, at 9:57 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
Thanks for the feedback! See my answers inline.
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/
I finally figured out how to make caching work. This webrev contains
On Feb 20, 2014, at 9:57 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
Thanks for the feedback! See my answers inline.
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/
I finally figured out how to make caching work. This webrev contains
This change was intended to end up in 7u40 but for some reason we missed it.
The original bug which went into 8 is:
https://bugs.openjdk.java.net/browse/JDK-8019184
and the pushed changeset:
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bd6949f9dbb2
This is the new 7u60 backport with
/hotspot-dev/2013-July/010118.html
thanks,
-jeff
On Feb 12, 2014, at 1:53 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
This change was intended to end up in 7u40 but for some reason we missed it.
The original bug which went into 8 is:
https
?
It was pushed in 2013:
author twisti
Wed Jul 03 11:35:06 2013 -0700 (7 months ago)
and the file wasn’t touched in 2014 so it’s fine.
-jeff
On Feb 12, 2014, at 4:14 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
On Feb 12, 2014, at 1:06 PM, Jeff Dinkins jeff.dink
Thanks for the information. I agree that it is annoying that people without an
OpenJDK username cannot log into JBS and add comments. I hope this will change
some day.
Maybe this is a missing backport of a fix in 8. Will start to dig...
On Feb 7, 2014, at 6:01 AM, Cédric Champeau
Looks good.
On Jan 30, 2014, at 4:58 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8033278
The fix for 8032585 [1] introduced a regression: in some cases access
check on a reference
I cannot comment on the performance impact but the change looks good.
On Jan 31, 2014, at 6:58 PM, serguei.spit...@oracle.com wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Open webrev:
Looks good.
On Jan 30, 2014, at 4:58 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8033278
The fix for 8032585 [1] introduced a regression: in some cases access
check on a reference
Looks good.
On Jan 27, 2014, at 8:05 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8032585
JSR292 access verification logic refuses method handle lookup access to
methods which are
Looks good.
On Jan 21, 2014, at 12:41 AM, Olivier Lagneau olivier.lagn...@oracle.com
wrote:
Please find the new webrev with copyright date fixed (changed to 2014).
Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.01/
Olivier.
Olivier Lagneau said on date 1/20/2014 5:50 PM:
https://bugs.openjdk.java.net/browse/JDK-8031043
http://cr.openjdk.java.net/~twisti/8031043/webrev.00
8031043: ClassValue's backing map should have a smaller initial size
Reviewed-by:
The current initial size for ClassValue's backing WeakHashMap (ClassValueMap)
is:
private static
[I’m resending something I sent earlier today to Vladimir directly.]
On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8031502
InvokeBytecodeGenerator can produce
On Jan 15, 2014, at 11:41 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Chris,
Thanks for looking into this. See my answers inline.
Best regards,
Vladimir Ivanov
On 1/15/14 9:51 PM, Christian Thalinger wrote:
[I’m resending something I sent earlier today to Vladimir
[I’m resending something I sent earlier today to Vladimir directly.]
On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8031502
InvokeBytecodeGenerator can produce
On Jan 15, 2014, at 11:41 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Chris,
Thanks for looking into this. See my answers inline.
Best regards,
Vladimir Ivanov
On 1/15/14 9:51 PM, Christian Thalinger wrote:
[I’m resending something I sent earlier today to Vladimir
On Jan 9, 2014, at 2:46 AM, Jochen Theodorou blackd...@gmx.org wrote:
Am 08.01.2014 21:45, schrieb Christian Thalinger:
[...]
If we’d go with an initial value of 1 would it be a performance problem for
you if it grows automatically?
that means the map will have to grow for hundreds
would definitely be a good
for us.
Thanks!
From: Christian Thalinger
christian.thalin...@oracle.commailto:christian.thalin...@oracle.com
Reply-To: Da Vinci Machine Project
mlvm-dev@openjdk.java.netmailto:mlvm-dev@openjdk.java.net
Date: Tuesday, 7 January 2014 22:54
To: Da Vinci Machine
On Jan 8, 2014, at 12:21 AM, Remi Forax fo...@univ-mlv.fr wrote:
On 01/07/2014 11:54 PM, Christian Thalinger wrote:
Can I get some comments on this bug from people who are using ClassValue?
[#JDK-8031043] ClassValue's backing map should have a smaller initial
size - Java Bug System https
On Jan 8, 2014, at 6:43 AM, Jochen Theodorou blackd...@gmx.org wrote:
Am 07.01.2014 23:54, schrieb Christian Thalinger:
Can I get some comments on this bug from people who are using ClassValue?
[#JDK-8031043] ClassValue's backing map should have a smaller initial
size - Java Bug System
Can I get some comments on this bug from people who are using ClassValue?
[#JDK-8031043] ClassValue's backing map should have a smaller initial size -
Java Bug System
Is my assumption correct that most language runtimes only attach a small number
of values (maybe only one) or that it wouldn’t
Why are we using a different file for the inline data?
On Dec 27, 2013, at 6:15 PM, Vladimir Kozlov vladimir.koz...@oracle.com wrote:
http://cr.openjdk.java.net/~kvn/8028468/webrev/
https://bugs.openjdk.java.net/browse/JDK-8028468
Add inlining information into Compilation Replay data to
Right. Thanks for clarifying, Alejandro. I just didn’t want to do another
push without the required approvals :-)
On Dec 23, 2013, at 6:40 AM, Alejandro E Murillo alejandro.muri...@oracle.com
wrote:
On 12/20/2013 12:14 PM, Christian Thalinger wrote:
https://bugs.openjdk.java.net/browse
https://bugs.openjdk.java.net/browse/JDK-8030059
The bug was originally filed against 7u40 but turned out that we have the same
problem in 8 so we pushed to 8 first:
https://bugs.openjdk.java.net/browse/JDK-8029366
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b87211e33ebb
This is the
What about BSD?
On Dec 17, 2013, at 4:08 PM, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
This is a change which enables additional compiler warnings for native
compilation when using GCC. The (-Wformat -Wformat-security) options are
supported by GCC 3.0.4 (the earliest version I
On Dec 11, 2013, at 12:17 AM, Mark Roos mr...@roos.com wrote:
So I updated to b119 and changed some callsite signatures from using Object[]
to Object...
// public static RtCallSite bootStrapSelf(MethodHandles.Lookup
callerLookup, String name, MethodType type, Object[] arg) {
https://bugs.openjdk.java.net/browse/JDK-8026502
8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms
The HotSpot part of the fix was missing.
This is a retroactive approval request because it was pushed already
accidentally:
Changeset: 271f0c186798
Author:twisti
Date: 2013-10-23 15:44 -0700
URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/271f0c186798
8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms
Reviewed-by: iveresov, jrose
!
Vote: yes
On Nov 22, 2013, at 5:47 AM, Alan Bateman alan.bate...@oracle.com wrote:
I hereby nominate Stuart Marks to jdk8 Reviewer.
Stuart has Committer role in the jdk8, jdk7u and lambda projects. He has been
contributing changes to OpenJDK for almost 3 years. He is author to more than
Changeset: 66884b270b44
Author:twisti
Date: 2013-10-24 10:52 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/66884b270b44
8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms
Reviewed-by: iveresov, jrose
!
Changeset: 66884b270b44
Author:twisti
Date: 2013-10-24 10:52 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/66884b270b44
8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms
Reviewed-by: iveresov, jrose
!
Changeset: 66884b270b44
Author:twisti
Date: 2013-10-24 10:52 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/66884b270b44
8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms
Reviewed-by: iveresov, jrose
!
Since I’ve already updated to Mavericks I’m looking into HotSpot build
failures. I have a couple of fixes but I’m not sure if I’m able to push them
for 8.
On Oct 24, 2013, at 10:34 AM, Jim Laskey (Oracle) james.las...@oracle.com
wrote:
I understood that the build team was postponing use of
On Oct 11, 2013, at 9:40 AM, Dalibor Topic dalibor.to...@oracle.com wrote:
With 7u40 being out of the door, it's time to update the jdk7u maintainer
team again.
I'd like to start by thanking Christian for his very welcome contributions as
a jdk7u
maintainer in the 7u40 endgame. As he
Thanks for the report. This seems to be a real issue and one of our engineers
filed:
https://bugs.openjdk.java.net/browse/JDK-8026288
On Oct 10, 2013, at 1:32 AM, Julien Ponge julien.po...@gmail.com wrote:
Hello,
The runtime of Golo (http://golo-lang.org/) makes several uses of
src/share/classes/java/lang/invoke/MethodHandles.java:
You have renamed coll to filter but the documentation still references
coll in multiple places, e.g.:
+ * If the filter method handle {@code coll} consumes one argument and
produces
+ * a non-void result, then {@code
src/share/classes/java/lang/invoke/MethodHandles.java:
You have renamed coll to filter but the documentation still references
coll in multiple places, e.g.:
+ * If the filter method handle {@code coll} consumes one argument and
produces
+ * a non-void result, then {@code
as
posted. — John
I'm fine with that.
On Oct 4, 2013, at 11:34 AM, John Rose john.r.r...@oracle.com wrote:
Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param
also. — John
On Oct 4, 2013, at 11:17 AM, Christian Thalinger
christian.thalin...@oracle.com wrote:
You
On Oct 2, 2013, at 2:31 PM, John Rose john.r.r...@oracle.com wrote:
On Oct 2, 2013, at 12:14 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
src/share/classes/java/lang/invoke/MethodHandles.java:
+ * tha name=equiv/alookup expression/th
Apparently the name
Looks good.
On Oct 2, 2013, at 12:33 PM, John Rose john.r.r...@oracle.com wrote:
Push-button webrev generator to the rescue:
http://cr.openjdk.java.net/~jrose/8024599/webrev.01
— John
On Oct 2, 2013, at 11:23 AM, Christian Thalinger
christian.thalin...@oracle.com wrote:
Since
Vote: yes
On Oct 1, 2013, at 10:13 PM, Alan Bateman alan.bate...@oracle.com wrote:
I hereby nominate Staffan Larsen to jdk8 Reviewer.
Staffan leads the serviceability area in Oracle's JDK team and has been
contributing changes to OpenJDK since Dec 2010. He has Reviewer role on the
hsx
Since there is no new webrev I assume you incorporated all the stuff below. If
that's the case then it looks good.
On Sep 20, 2013, at 6:18 PM, John Rose john.r.r...@oracle.com wrote:
On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
John,
I don't see
Looks good.
On Oct 1, 2013, at 2:29 PM, John Rose john.r.r...@oracle.com wrote:
Second call for reviews. I need two official Reviewers for this change. —
John
P.S. Thanks for your comments Morris; I enhanced the comment:
+// The JVM does this hack also.
++ // (See
src/share/classes/java/lang/invoke/MethodHandles.java:
+ * tha name=equiv/alookup expression/th
Apparently the name attribute is obsolete for a/ in HTML5:
http://dev.w3.org/html5/markup/a.html
I think they want you to use th id=equiv.
+ * p style=font-size:smaller;
+ * a
Thank you for doing this; it is much clearer now. Looks good.
On Oct 1, 2013, at 10:19 PM, John Rose john.r.r...@oracle.com wrote:
Chris Thalinger suggested removing the new booleans from the changed
getDirectMethod call sites and instead put the intended usage into the
method names, e.g.,
On Sep 20, 2013, at 5:09 PM, John Rose john.r.r...@oracle.com wrote:
On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
I cleaned javadoc a little [1], so it is more readable in the browser now.
Thanks; I applied those edits. I fixed the problem of a
Since there is no new webrev I assume you incorporated all the stuff below. If
that's the case then it looks good.
On Sep 20, 2013, at 6:18 PM, John Rose john.r.r...@oracle.com wrote:
On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
John,
I don't see
Thank you for doing this; it is much clearer now. Looks good.
On Oct 1, 2013, at 10:19 PM, John Rose john.r.r...@oracle.com wrote:
Chris Thalinger suggested removing the new booleans from the changed
getDirectMethod call sites and instead put the intended usage into the
method names, e.g.,
On Sep 20, 2013, at 5:09 PM, John Rose john.r.r...@oracle.com wrote:
On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
I cleaned javadoc a little [1], so it is more readable in the browser now.
Thanks; I applied those edits. I fixed the problem of a
Looks good.
On Sep 27, 2013, at 5:39 AM, Sergey Kuksenko sergey.kukse...@oracle.com wrote:
Updated version at
http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.02/
according comments:
- remove null check comment near Object.requireNonNull calls
- distort/(change parameters
On Sep 18, 2013, at 6:43 PM, John Rose john.r.r...@oracle.com wrote:
On Sep 18, 2013, at 2:11 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
src/share/classes/java/lang/invoke/CallSite.java:
+if (3 + argv.length MethodType.MAX_MH_ARITY
necessary to get
the error, so it is not only shell-free, it can also be run outside jtreg.
On 2013-09-12, at 2:34 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
On Sep 12, 2013, at 11:28 AM, David Chase david.r.ch...@oracle.com
wrote:
New webrev, commented line removed
On Sep 19, 2013, at 2:31 PM, John Rose john.r.r...@oracle.com wrote:
On Sep 18, 2013, at 5:05 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
src/share/classes/java/lang/invoke/MethodHandles.java:
+ * methods as if they were normal methods, but the JVM verifier
On Sep 26, 2013, at 7:20 AM, Jochen Theodorou blackd...@gmx.org wrote:
Hi all,
probably not such a good time to ask, since many of those, that could
answer this might be on JavaOne... but still
On the user list we got an interesting program that makes quite some
problems to the jvm as
On Sep 25, 2013, at 10:52 AM, Francis ANDRE francis.andre.kampb...@orange.fr
wrote:
Hi
On WXP with VS2010 and the http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/
repository, I successfully build and ran the debug version of hotspot in
compiler1 directory. fine
Next, I tried to get
Changeset: 78b4dc33e6e6
Author:twisti
Date: 2013-09-26 18:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78b4dc33e6e6
8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
Reviewed-by: jrose
! src/share/classes/java/lang/invoke/MemberName.java
On Sep 26, 2013, at 1:22 AM, Peter Levart peter.lev...@gmail.com wrote:
On 09/26/2013 01:27 AM, Christian Thalinger wrote:
http://cr.openjdk.java.net/~twisti/8019192/webrev/
8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
Reviewed-by:
This is a race in MemberName's
On Sep 26, 2013, at 9:22 AM, Sergey Kuksenko sergey.kukse...@oracle.com wrote:
Hi All,
I updated fix.
You may find it here
http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.01/
The change looks good. Since we use Objects.requireNonNull now we can remove
the null check comment:
On Sep 26, 2013, at 11:50 AM, Christian Thalinger
christian.thalin...@oracle.com wrote:
On Sep 26, 2013, at 1:22 AM, Peter Levart peter.lev...@gmail.com wrote:
On 09/26/2013 01:27 AM, Christian Thalinger wrote:
http://cr.openjdk.java.net/~twisti/8019192/webrev/
8019192
On Sep 26, 2013, at 2:28 PM, John Rose john.r.r...@oracle.com wrote:
On Sep 26, 2013, at 1:13 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
On Sep 26, 2013, at 11:50 AM, Christian Thalinger
christian.thalin...@oracle.com wrote:
On Sep 26, 2013, at 1:22 AM, Peter
and name can actually be null is the
tricky part. Someone down the line in 5 years might not know about this
conversation and be surprised.
your call of course, just looks odd as-is.
Sent from my phone
On Sep 26, 2013 8:15 PM, Christian Thalinger
christian.thalin...@oracle.com wrote
necessary to get
the error, so it is not only shell-free, it can also be run outside jtreg.
On 2013-09-12, at 2:34 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
On Sep 12, 2013, at 11:28 AM, David Chase david.r.ch...@oracle.com
wrote:
New webrev, commented line removed
On Sep 19, 2013, at 2:31 PM, John Rose john.r.r...@oracle.com wrote:
On Sep 18, 2013, at 5:05 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
src/share/classes/java/lang/invoke/MethodHandles.java:
+ * methods as if they were normal methods, but the JVM verifier
This looks good. Thank you for changing it to template methods instead of
using macros.
On Sep 23, 2013, at 2:17 PM, Lois Foltan lois.fol...@oracle.com wrote:
Please review the following updated fix which has removed the CAST_*_OOP macro
implementation in favor of two inlined template
http://cr.openjdk.java.net/~twisti/8019192/webrev/
8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
Reviewed-by:
This is a race in MemberName's name and type getters.
MemberName's type field is of type Object so it can hold different objects when
it gets filled in from the
On Sep 19, 2013, at 3:19 PM, Lois Foltan lois.fol...@oracle.com wrote:
On 9/19/2013 6:09 PM, Christian Thalinger wrote:
+ #define CAST_TO_OOP(value) ((oop)(CHECK_UNHANDLED_OOPS_ONLY((void
*))(value)))
+ #define CAST_FROM_OOP(new_type, value)
((new_type)(CHECK_UNHANDLED_OOPS_ONLY((void
+ #define CAST_TO_OOP(value) ((oop)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value)))
+ #define CAST_FROM_OOP(new_type, value)
((new_type)(CHECK_UNHANDLED_OOPS_ONLY((void *))(value)))
Could these two macros also be a method?
On Sep 19, 2013, at 8:13 AM, Lois Foltan lois.fol...@oracle.com wrote:
On Sep 19, 2013, at 4:22 PM, Lois Foltan lois.fol...@oracle.com wrote:
On 9/19/2013 6:27 PM, Christian Thalinger wrote:
On Sep 19, 2013, at 3:19 PM, Lois Foltan lois.fol...@oracle.com wrote:
On 9/19/2013 6:09 PM, Christian Thalinger wrote:
+ #define CAST_TO_OOP(value) ((oop
On Sep 19, 2013, at 6:06 PM, Lois Foltan lois.fol...@oracle.com wrote:
On 9/19/2013 7:25 PM, Christian Thalinger wrote:
On Sep 19, 2013, at 4:22 PM, Lois Foltan lois.fol...@oracle.com wrote:
On 9/19/2013 6:27 PM, Christian Thalinger wrote:
On Sep 19, 2013, at 3:19 PM, Lois Foltan
On Sep 16, 2013, at 2:59 AM, Charles Oliver Nutter head...@headius.com wrote:
On Mon, Sep 16, 2013 at 2:36 AM, John Rose john.r.r...@oracle.com wrote:
I have refreshed mlvm-dev and pushed some patches to it which may address
this problem.
I'll get a build put together and see if I can get
src/share/classes/java/lang/invoke/CallSite.java:
+if (3 + argv.length MethodType.MAX_MH_ARITY)
+MethodType invocationType = MethodType.genericMethodType(3
+ argv.length);
+MethodHandle spreader =
src/share/classes/java/lang/invoke/MethodHandles.java:
+ * methods as if they were normal methods, but the JVM verifier rejects
them.
I think you should say JVM byte code verifier here.
+ * em(Note: JVM internal methods named {@code init} not visible
to this API,
+ * even
On Sep 18, 2013, at 1:39 AM, Charles Oliver Nutter head...@headius.com wrote:
I've been playing with JMC a bit tonight, running a user's application
that's about 2x slower using indy than using trivial monomorphic
caches (and no indy call sites). I'm trying to understand how to
interpret
src/share/classes/java/lang/invoke/MethodHandles.java:
+ * methods as if they were normal methods, but the JVM verifier rejects
them.
I think you should say JVM byte code verifier here.
+ * em(Note: JVM internal methods named {@code init} not visible
to this API,
+ * even
Looks good.
On Sep 12, 2013, at 6:02 PM, John Rose john.r.r...@oracle.com wrote:
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001109/webrev.00/
The change is mostly to javadoc and unit tests, documenting and testing some
corner
+ // err.initCause(ex);
Why is this commented?
-- Chris
On Sep 6, 2013, at 4:59 PM, David Chase david.r.ch...@oracle.com wrote:
new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
Same small changes to the sources, plus a test.
bug: wrong exception was
exceptions that lead to the defined exception being thrown. The commented
line should have just been removed (I think).
On 2013-09-12, at 1:24 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
+ // err.initCause(ex);
Why is this commented?
-- Chris
On Sep 12, 2013, at 4:34 PM, John Rose john.r.r...@oracle.com wrote:
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8019417/webrev.00
The change is to javadoc and unit tests, documenting and testing some corner
cases of JSR 292
+ // err.initCause(ex);
Why is this commented?
-- Chris
On Sep 6, 2013, at 4:59 PM, David Chase david.r.ch...@oracle.com wrote:
new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
Same small changes to the sources, plus a test.
bug: wrong exception was
exceptions that lead to the defined exception being thrown. The commented
line should have just been removed (I think).
On 2013-09-12, at 1:24 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
+ // err.initCause(ex);
Why is this commented?
-- Chris
On Sep 12, 2013, at 4:34 PM, John Rose john.r.r...@oracle.com wrote:
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8019417/webrev.00
The change is to javadoc and unit tests, documenting and testing some corner
cases of JSR 292
On Sep 5, 2013, at 12:31 AM, Dmitry Samersoff dmitry.samers...@oracle.com
wrote:
On 2013-09-05 02:30, Christian Thalinger wrote:
On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff dmitry.samers...@oracle.com
wrote:
Please, review the changes.
http://cr.openjdk.java.net/~dsamersoff/JDK
-11 20:37, Christian Thalinger wrote:
On Sep 5, 2013, at 12:31 AM, Dmitry Samersoff dmitry.samers...@oracle.com
wrote:
On 2013-09-05 02:30, Christian Thalinger wrote:
On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff dmitry.samers...@oracle.com
wrote:
Please, review the changes.
http
101 - 200 of 1313 matches
Mail list logo
