On Nov 4, 2013, at 1:37 PM, Remi Forax fo...@univ-mlv.fr wrote:
Note that while this fix is ok now,
it introduced a performance regression, doing reflection on a functional
method of an inner class
is faster than doing reflection on the functional method of a lambda proxy.
This particular
On Nov 6, 2013, at 11:30 AM, Peter Levart peter.lev...@gmail.com wrote:
Well, indexOf(char) or lastIndexOf(char) searches for a single char. We can
do better searching backwards for two chars at the same time.
If the name of VM-anonymous class is always ending with pattern: slash
followed
Reviewed. Thanks for the fix. The test case will also be a useful quick test
for unboxed catchEx paths. — John
On Nov 8, 2013, at 7:25 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8027823/webrev.00/
MethodHandleImpl.makeGuardWithCatch has
Ivanov
On 11/9/13 3:26 AM, John Rose wrote:
Reviewed. Thanks for the fix. The test case will also be a useful quick
test for unboxed catchEx paths. — John
On Nov 8, 2013, at 7:25 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8027823
On Nov 11, 2013, at 2:14 PM, Brian Goetz brian.go...@oracle.com wrote:
I believe a long time ago it used to work this way; there was a private
handoff constructor in String that StringBuffer would use. Probably got
changed when we added StringBuilder?
As you might expect, we've been
On Nov 11, 2013, at 4:58 AM, Peter Levart peter.lev...@gmail.com wrote:
Hi John, Remi,
I tried to create a prototype to see how it compares to bytecode-generated
method accessor. Here it is:
https://bugs.openjdk.java.net/browse/JDK-6824466#comment-13426571
It seems that lambda forms
On Nov 14, 2013, at 7:21 PM, Joseph Darcy joe.da...@oracle.com wrote:
Catching up on email, the specification of java.lang.Class does not
explicitly promise that its notion of equality must be identity for all time.
Therefore, while not required for today's implementations, I would prefer
On Nov 20, 2013, at 4:31 PM, Remi Forax fo...@univ-mlv.fr wrote:
But while you can declare a default hashCode and equals, it will not work
because the implementation of Object.hashCode and Object.equals will always
be preferred to the default methods by the VM, this is how default methods
On Nov 25, 2013, at 1:49 AM, Paul Sandoz paul.san...@oracle.com wrote:
Just curious: why did you chose to add the method, throwIllegalAccessError,
to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than
modifying an existing pre-loaded class?
Unsafe is used everywhere,
On Nov 22, 2013, at 11:07 AM, David Chase david.r.ch...@oracle.com wrote:
Webrev(s):
http://cr.openjdk.java.net/~drchase/8016839/webrev-hotspot.01/
http://cr.openjdk.java.net/~drchase/8016839/webrev-jdk.01/
Excellent work. Count me as reviewer, please. — John
I appreciate the report and the proposed fixes. We are looking at this
seriously.
— John
P.S. The root issue may be an accidental inheritance of private methods. I
have been thinking for a while that, in the name of compatibility, the JVMS
allows an invokevirtual invocation to reach a
On Jan 15, 2014, at 6:49 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
John would know the answer.
Given this change should go into JDK 8 I think we should push for now. If we
can come up with a better way to handle these situations we can push another
change for 9 or
This is safe as a point fix, since (a) Lookup.checkSymbolicClass vets 'refc'
before checkMemberAccess is called, and (b) the JVMS does not in fact call for
'defc' to also be accessible, if it is inherited via 'refc'.
There is a slightly different problem here, a code cleanup problem. The
On Feb 20, 2014, at 12:09 PM, David Holmes david.hol...@oracle.com wrote:
If the sentinel values were the default zero values there would be no issue
This is an instance of the stable value pattern; see the javadoc for
java/lang/invoke/Stable.
Using zero for the sentinel in this pattern is
On Feb 20, 2014, at 9:57 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/
I finally figured out how to make caching work. This webrev contains these
changes.
I changed LF representation a bit and added
On Feb 25, 2014, at 5:17 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
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) {
+ //
On Feb 25, 2014, at 4:16 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
As an interim fix, I moved castReference method into
java.lang.invoke.MethodHandleImpl class and added new entry point
ValueConversions::cast which accepts a method handle to a method which
should be used for
On Feb 26, 2014, at 3:44 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Maybe use invokeWithArguments with target and catcher? That at least is
a one-liner, and probably more efficient.
Yes, that's a good idea! At least, it considerably simplifies the code.
Updated webrev:
On Feb 25, 2014, at 3:13 AM, Ali Ebrahimi ali.ebrahimi1...@gmail.com wrote:
I know, this is too late, but I want to share my suggestion:
public T extends AccessibleObjectAnnotatedElement T reflectAs(Class?
super T expected, MethodHandles.Lookup lookup)
Isn't this the same as
public T
On Feb 28, 2014, at 1:38 AM, Paul Sandoz paul.san...@oracle.com wrote:
But chances are, the day after I take it off, I will need it.
tryMonitorEnter() does no harm and it is out of reach of most programmers.
I think your analogy to a spare wheel is misleading. Continuing with the car
On Mar 4, 2014, at 7:41 PM, David Holmes david.hol...@oracle.com wrote:
I agree it is as unsafe as using Lock. I think not being able to forget to
unlock a monitor is more than just convenient. YMMV and obviously does.
That's why that unsafe kind of stuff currently lives in class unsafe.
Reviewed.
– John
On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Chris, thanks for the review.
John suggested an elegant way to fix the problem - use asFixedArity.
Updated fix:
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/
Best regards,
I think that we've covered all the angles, and that we can remove it.
– John
On Mar 12, 2014, at 1:44 PM, Paul Sandoz paul.san...@oracle.com wrote:
Currently i cannot find any external uses of it.
of this
object has no monitor. Probably the keyword cannot be repurposed but would
eventually be deprecated. And the Moon will reach Roche limit.
– John
On Mar 12, 2014, at 2:12 PM, John Rose john.r.r...@oracle.com wrote:
I think that we've covered all the angles, and that we can remove
On Mar 13, 2014, at 4:21 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Mar 12, 2014, at 10:23 PM, John Rose john.r.r...@oracle.com wrote:
P.S. FTR, I wish we could also remove the per-object monitor from its
privileged position, so not all objects are burdened by it, and other forms
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)
that you can't assign an int or char to a byte w/o a cast.
That's why it
On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Thanks for the feedback.
What do you think about the following:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/
That looks nice. Strong typing; who woulda' thunk it. :-)
The uses of .ordinal() are
On Mar 28, 2014, at 2:29 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
PS: John mentioned recently that there's a convention for java/lang/invoke
tests to be in JUnit format. I'm not sure it'll improve the code in any way
(maybe TestNG will?). I hope John will express his opinion
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 to use different
names just because they are used in other namespaces.
Reviewed. — John
On May 15, 2014, at 10:48 AM, Christian Thalinger
christian.thalin...@oracle.com wrote:
https://bugs.openjdk.java.net/browse/JDK-8032606
http://cr.openjdk.java.net/~twisti/8032606/webrev.00
8032606: ClassValue.ClassValueMap.type is unused
Reviewed-by:
On May 16, 2014, at 4:56 AM, Tobias Hartmann tobias.hartm...@oracle.com wrote:
Is it sufficient then to use synchronized (lambdaForms) { ... } in
setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
Yes, that is how I see it. The fast path is a racy non-volatile read of a
Reviewed.
This is not a requirement, but I would prefer (in general) to see less test
logic in ASM-generated bytecode and more in Java. I am guessing that the
invokeExact call could have been replaced by a simple weakly-typed invoke call
in the framing code, and likewise with most of the
Reviewed. — John
On Jun 16, 2014, at 9:50 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8046903/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8046903
j.l.i.InvokerBytecodeGenerator::isStaticallyInvocable doesn't distinguish
between VM
Regarding the extra cast in accessor logic that Paul picked up on: That may be
a left-over from obsolete versions of the code, or it may cover for some corner
cases, or it could possibly be a re-assurance to the JIT.
Generally speaking, we lean heavily on MH types to guarantee a priori
On Jul 9, 2014, at 3:14 AM, Paul Sandoz paul.san...@oracle.com wrote:
I quickly verified the fold up does as you expect. Also, if i do the
following the null check goes away:
...
void testLoop() {
for (int i = 0; i 100; i++) {
testLoopOne(a);
On Jul 11, 2014, at 10:56 AM, Remi Forax fo...@univ-mlv.fr wrote:
On 07/11/2014 06:18 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8050052
I've found myself writing the very same code as
On Jul 16, 2014, at 11:20 AM, Peter Levart peter.lev...@gmail.com wrote:
An alternative could be:
public Throwable throwIfUnchecked() {
if (this instanceof RuntimeException) throw (RuntimeException) this;
if (this instanceof Error) throw (Error) this;
return this;
}
Then use it
FTR, I captured this issue:
https://bugs.openjdk.java.net/browse/JDK-8051294
(Wish they were all so easy to catch.)
— John
On Jul 17, 2014, at 5:12 PM, John Rose john.r.r...@oracle.com wrote:
On Jul 16, 2014, at 11:20 AM, Peter Levart peter.lev...@gmail.com wrote:
An alternative could
On Jul 18, 2014, at 1:15 PM, Remi Forax fo...@univ-mlv.fr wrote:
I like the way the proposed API is composable but i fear that people will
still forget to first call throwIfUnchecked() most of the time.
I think we should not implement a throwSuppressedIf because a suppressed
exception is
On Aug 27, 2014, at 6:48 AM, Fabian Lange lange.fab...@gmail.com wrote:
Hi all,
I have been involved recently in some theoretical or nonsensical
discussions about microbenchmarking, jit compiling assemblies and so fort.
One example was LinkedList vs ArrayList.
What I noticed is that those
On Aug 28, 2014, at 7:38 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Jul 8, 2014, at 9:09 PM, John Rose john.r.r...@oracle.com wrote:
Regarding the extra cast in accessor logic that Paul picked up on: That may
be a left-over from obsolete versions of the code, or it may cover for some
On Aug 29, 2014, at 1:05 PM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Thanks for explaining this, but a very little nit: the immediate (I.e. -1)
uses additional 32/64 bits in code which must be loaded from memory and
wastes space in CPU cache or am I wrong? This could be saved with = 0.
I have
On Aug 29, 2014, at 5:27 PM, Martin Buchholz marti...@google.com wrote:
I agree that the benefit is very small, but I am coming at this from source
code consistency and bytecode size (not jitted code performance), and I think
bytecode size is at least one of the problems with assert.
We
David Chase and I just noticed files like this in the JDK:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/test/java/util/stream/test/org/openjdk/tests/java/util/stream/
The package for the test code is org.openjdk.tests.java.util.stream.
Although that's long, it is completely unambiguous.
On Jul 16, 2014, at 1:50 AM, Paul Sandoz paul.san...@oracle.com wrote:
Why not make the second parameter be DirectMethodHandle mh ?
Good suggestion; thanks. Makes the restrictReceiver logic less magic. — John
On Aug 30, 2014, at 7:17 AM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Am 30.08.2014 um 01:33 schrieb John Rose:
On Aug 29, 2014, at 1:05 PM, Ulf Zibis ulf.zi...@cosoco.de
mailto:ulf.zi...@cosoco.de wrote:
Thanks for explaining this, but a very little nit: the immediate (I.e. -1)
uses
On Aug 30, 2014, at 10:58 AM, Doug Lea d...@cs.oswego.edu wrote:
In the present case, I'm with Martin about short-circuiting
this with a simple approximate answer: Rather than flip a coin
choosing between solutions A and B, pick the one with smaller bytecode.
This has a decent enough
Reviewed.
Nice tuning of the asserts.
— John
On Sep 15, 2014, at 9:03 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8058291/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8058291
8057656 8050166 changes accidentally removed some checks
Reviewed.
On Sep 17, 2014, at 4:09 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8058626/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8058626
I've noticed a difference between 8057656 fixes in 8u-dev [1] and 9 [2].
It seems I
On Oct 10, 2014, at 2:20 PM, Remi Forax fo...@univ-mlv.fr wrote:
I have another question about inOptimizer(),
thinkint a little about it, if there is a code like
if (unsafe.inOptimizer()) {
...
}
this code will always trigger a recompilation, at least once, because in the
On Jan 26, 2013, at 4:50 AM, Chris Hegarty wrote:
To be clear I'm not saying this can't happen. I'm just saying that the right
people need to ensure that all the necessary pieces are in place, and the
procedures established before we actually start doing it on a regular basis.
Yes, I
On Feb 8, 2013, at 10:38 AM, Krystal Mo krystal...@oracle.com wrote:
For the record, credit goes to John Rose who did the actual fix. I only added
the unit test to verify the fix.
Also FTR, your unit test found a bug which led you to amend the fix. So the
final version of the fix, as well
On Feb 11, 2013, at 6:34 PM, Krystal Mo krystal...@oracle.com wrote:
Let's get John's comment and see if my understanding of that part is correct.
The new code treats findSpecial and unreflectSpecial as corner cases. In these
corner cases, refKind is invokespecial, *and* this is visible to
On Feb 11, 2013, at 6:34 PM, Krystal Mo krystal...@oracle.com wrote:
This might look a bit hacky...
The idea is, DirectMethodHandle.make(Class? receiver, MemberName member)
should keep its behavior as it used to
P.S. I wonder if we could get rid of that old overloading of
Good fix; thumbs up. — John
On Feb 8, 2013, at 10:19 AM, Kumar Srinivasan kumar.x.sriniva...@oracle.com
wrote:
Hi,
Please review
http://cr.openjdk.java.net/~ksrini/8007519/webrev.0/
Bug:
https://jbs.oracle.com/bugs/browse/JDK-8007519
Thanks
Kumar
On Mar 2, 2013, at 12:46 AM, Jeroen Frijters jer...@sumatra.nl wrote:
This is really great. I've been using an annotation for caller sensitive
methods for many year in IKVM as a performance enhancement and I can say that
my experiences with my simple mechanism are really great.
Hi Jeroen.
On Mar 19, 2013, at 1:14 PM, Mandy Chung mandy.ch...@oracle.com wrote:
javaClasses.hpp - MN_CALLER_SENSITIVE and MN_SEARCH_SUPERCLASSES have the
same value. Should they be different?
1057 MN_CALLER_SENSITIVE = 0x0010, // @CallerSensitive annotation
detected
1061
On Mar 27, 2013, at 10:35 AM, Mandy Chung mandy.ch...@oracle.com wrote:
1. I am working on a fix for 8007035 that proposes to deprecate
SecurityManager.checkMemberAccess method as it requires the caller’s frame to
be at a stack depth of four, which is fragile and difficult to enforce.
Where
On Mar 27, 2013, at 10:35 AM, Mandy Chung mandy.ch...@oracle.com wrote:
This is the JDK change for JEP 176: JEP 176: Mechanical Checking of
Caller-Sensitive Methods [1]. Christian has posted the webrev for the
hotspot VM change a couple weeks ago [2].
Webrev at:
So getDM has a bug and getM is correct wrt inheritance. Thanks Peter!
-- John (on my iPhone)
On Apr 2, 2013, at 3:25 PM, Mandy Chung mandy.ch...@oracle.com wrote:
Are you concerned the overhead of an exception thrown that we should avoid?
On Apr 3, 2013, at 12:52 PM, Jeroen Frijters jer...@sumatra.nl wrote:
Thanks for this. This is a really great change.
I reviewed the changes and my only comment is that there is a typo in
java/lang/reflect/Field.java (scurity).
Thanks!
Somewhat unrelated (but relevant for my
On Apr 3, 2013, at 11:00 PM, Jeroen Frijters jer...@sumatra.nl wrote:
Given the ability to create constructorless subclasses, it really should be
combined with making the class final.
My current rules for @CallerID (which unlike @CallerSensitive is not just
about semantics, but also about
On Apr 19, 2013, at 9:41 AM, Bharadwaj Yadavalli
bharadwaj.yadava...@oracle.com wrote:
I would like to request for a review of code changes made to support lambda
related modifications to allow static and invokespecial calls to interface
methods per spec version 0.6.2
On Apr 23, 2013, at 6:26 PM, Bharadwaj Yadavalli
bharadwaj.yadava...@oracle.com wrote:
I modified the assertion in referenceKindIsConsistent() to allow
REF_invokeSpecial to reference interface method. I have uploaded the modified
webrev.
Good, thanks. — John
On Apr 23, 2013, at 6:26 PM, Bharadwaj Yadavalli
bharadwaj.yadava...@oracle.com wrote:
Reran lambda tests successfully.
Just in case, be sure the jtreg tests in test/java/lang/invoke/ also pass, with
-ea -esa turned on. That's probably already true, but if there is a false fire
in the
On Apr 29, 2013, at 3:05 PM, Kumar Srinivasan kumar.x.sriniva...@oracle.com
wrote:
Please review this fix which will enable profiles and embedded distros to
eliminate the unpack200 binaries saving space, all this does is switch
to the java implementation if the native one cannot be found.
On Apr 30, 2013, at 11:32 AM, Kumar Srinivasan kumar.x.sriniva...@oracle.com
wrote:
Couple of nits:
I don't think you need the parens
j = (nextsemi nextangl ? nextsemi : nextangl);
I recommend (and many style guides recommend) adding extra parens in when the
operator precedence is
Puzzles!
Probably you can use the new syntax catch (Ex1|Ex2 ex) to bind the first
exception to a union type.
You'll have to split the loop, but you could use a common iterator.
for (Iterator it = all changes; it.hasNext(); ) {
try {
it.next(); once(); return;
} catch (One|Two ex) {
On Jun 27, 2013, at 6:43 PM, Joe Darcy joe.da...@oracle.com wrote:
Hi John,
Please review the changes for
8019357: Fix doclint warnings in java.lang.invoke
http://cr.openjdk.java.net/~darcy/8019357.0/
I read it and it is good. Thanks for doing this. — John
Good; 'andThen' is a more productive[1] term than 'chain'.
[1]: http://en.wikipedia.org/wiki/Productivity_(linguistics)
— John
Yes, this is a good tactic, but as written it is too much of a point hack for
lambdas (important though they are).
I have an alternate solution I would like you to measure. It provides a fast
path for other BSM lookups like Nashorn's, so (if it works well for lambda) it
is preferable.
I will
It looks good. I have three requests.
Regarding this comment:
+ * See MethodSupplier.java to see how to produce these bytes.
+ * They encode that class, except that method m is private, not public.
The recipe is incomplete, since it does not say which bits to tweak to make m
private.
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 APIs.
Since the RI is already correct, there are no implementation code
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 cases of JSR 292 APIs.
In the RI, the exception-raising code is simplified to throw
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001108/webrev.00
Summary: add an explicit check for leading , upgrade the unit tests
The change is mostly to javadoc and unit tests, documenting and testing some
corner cases of JSR 292
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
Summary: Align MH semantic with bytecode behavior of constructor and static
member accesses, regarding clinit invocation.
The change is to javadoc and unit tests,
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001110/webrev.00/
Summary: promote an existing private method; make unit tests on all argument
positions to arity 10 with mixed types
The change is to javadoc and unit tests, documenting
important
things to do.)
— John
David
On 2013-09-12, at 5:35 PM, John Rose john.r.r...@oracle.com wrote:
It looks good. I have three requests.
Regarding this comment:
+ * See MethodSupplier.java to see how to produce these bytes.
+ * They encode that class, except that method
P.S. To see the proposed JSR 292 spec changes only (no code, rendered
javadoc), see:
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/1-specdiff-meth-info-8008688
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/2-specdiff-meth-arity-8019417
Thanks for the heads up. I noticed this just now; after refreshing my repos
half of the tests fail.
Where is the doc that says how to run jtreg and ant (Netbeans) now that my
tests have been changed for me?
— John
On Aug 12, 2013, at 2:17 AM, Alan Bateman alan.bate...@oracle.com wrote:
On
vote for JDK-8024761 instead of
JDK-8024630. Because of your solution is general and performance
difference is not significant.
On 09/11/2013 10:18 PM, John Rose wrote:
Yes, this is a good tactic, but as written it is too much of a point hack
for lambdas (important though they are).
I have
The algorithmic change (string cache) is acceptable, although it will tend to
increase footprint somewhat. We can tweak that later if necessary. There are
probably only a small number of such strings, so maybe a small leaky map would
do the trick as well. What you propose is fine.
But,
On Sep 17, 2013, at 11:19 AM, Sergey Kuksenko sergey.kukse...@oracle.com
wrote:
On 09/17/2013 04:41 AM, John Rose wrote:
The algorithmic change (string cache) is acceptable, although it will tend
to increase footprint somewhat.
I don't think that it would be visible footprint increasing
/~jrose/8001108/webrev.01/
— John
On Sep 12, 2013, at 6:47 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/8001108/webrev.00
Summary: add an explicit check for leading , upgrade the unit tests
On Sep 12, 2013, at 7:24 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/8024599/webrev.00/
Summary: Align MH semantic with bytecode behavior of constructor and static
member accesses
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 missing p in a few
other places too.
The test code looks ok, though the logic
two ticks in between
assertEquals(t1+1, t2); // init happened inside
return t2;
— John
Best regards,
Vladimir Ivanov
On 9/20/13 1:38 AM, John Rose wrote:
On Sep 12, 2013, at 7:24 PM, John Rose john.r.r...@oracle.com
mailto:john.r.r...@oracle.com wrote:
Please review
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 Levart peter.lev...@gmail.com wrote:
On 09/26/2013 01:27 AM, Christian
On Sep 26, 2013, at 2:46 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
The problem I have with this is that some people might think the local
variable is the instance field. IDEs help here because they usually
highlight local variables and instance fields in different
On Sep 19, 2013, at 9:57 AM, David Chase david.r.ch...@oracle.com wrote:
Recommended changes made:
http://cr.openjdk.java.net/~drchase/8022701/webrev.04/
Good; reviewed.
Consider adding this tweak, which would close the loop on alternation between
the fooError and fooException versions:
+
) in key-purposed MethodType constructor
- move count-slot logic from checkPType to checkPTypes.
On 09/26/2013 11:09 PM, John Rose wrote:
(Quick note on format: I have changed the subject line to include the
conventional bug number and size estimate. The bug number makes it easier
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 much value in documenting buggy behavior of early JDK7 in JDK8
code. So, I would remove it.
OK
: September 26, 2013 6:46:23 PM PDT
To: Da Vinci Machine Project mlvm-...@openjdk.java.net
Cc: hotspot-compiler-...@openjdk.java.net compiler
hotspot-compiler-...@openjdk.java.net
Reply-To: Da Vinci Machine Project mlvm-...@openjdk.java.net
On Sep 18, 2013, at 6:43 PM, John Rose john.r.r
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 have renamed coll to filter but the documentation still references
coll in multiple places, e.g.:
+ *
Actually it's OK: The name coll is defined a couple lines up by the A
collection adapter {@code collectArguments(mh, 0, coll)} ..., and the term
filter is persistently applied to it. So I think it is intelligible as
posted. — John
On Oct 4, 2013, at 11:34 AM, John Rose john.r.r...@oracle.com
On Oct 9, 2013, at 11:49 AM, David Chase david.r.ch...@oracle.com wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8022718
webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.00/
Problem: Needed implementation for change to the spec for JVM behavior (from
the bug report):
On Oct 9, 2013, at 8:32 PM, David Holmes david.hol...@oracle.com wrote:
I'm unsure if it should be is null or are null given the initial subject
is singular and latter subject is plural.
The English major in me surfaces briefly to note that any can be either
singular or plural: Pick a
On Oct 10, 2013, at 3:44 PM, Brian Goetz brian.go...@oracle.com wrote:
maxSize
maxFoo suggests an inclusive limit to foo. fooLimit suggests an
exclusive limit.
For slice I suggest sizeLimit (limit with similar meaning to argument in
String.split or java.io.Reader.mark).
On Oct 9, 2013, at
8024635: Caching MethodType's descriptor string improves lambda linkage
performance
Summary: Better interpreted and compiled performance of operations in
MethodType important to LambdaMetafactory.
Reviewed-by: jrose, twisti, ?
Contributed-by: skuksenko
On Oct 31, 2013, at 1:05 PM, Mandy Chung mandy.ch...@oracle.com wrote:
Nit: maybe better to merge two constructors to explicitly specify if it wants
to skip the parameter validations (not sure if there is any reason for the
rtype and ptypes parameter order is different in the two ctors)
1 - 100 of 389 matches
Mail list logo
