Re: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86
Am 11.01.2013 23:53, schrieb Christian Thalinger: But you guys noticed that sentence in the initial review request, right? Move encoding loop into separate method for which VM will use intrinsic on x86. Just wanted to make sure ;-) Good question Christian! This is, how it shows up to me: 1) The bug synopsis is unspecific about intrinsc, so ... 2) the mentioned 1st sentence could be one of many solutions. 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 == This bug is not available. 4) What specific operation should be done by the intrinsic, i.e. is there a fixed API for that method ??? 5) Can an intrinsic write back more than 1 value (see my hack via int[] p) ? 6) Vladimir's webrev shows an integer as return type for that method, I've added a variant with boolean return type, and the code from my last approach could be transformed to a method with Object return type. ... so waiting for Vladimir's feedback :-[ (especially on performance/hsdis results) (Can someone push the bug to the public?) -Ulf
Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder
On 01/11/13 21:37, Joe Darcy wrote: I would prefer to cautionary note along the lines of if you want numerical accuracy, take care to use a summation algorithm with defined worst-case behavior. (Varying magnitude is not so much of a problem if you add things up in the right order.) Thanks. I do not believe such an algorithm exists, because no ordering control is possible, and all other known accuracy improvements (like Kahn) require multiword atomicity, which we explicitly do not provide. Which leaves me thinking that the current disclaimer (below) is the best we can do. -Doug The order of accumulation within or across threads is not guaranteed. Thus, this class may not be applicable if numerical stability is required, especially when combining values of substantially different orders of magnitude.
Re: Review request JDK-8004729: Parameter Reflection API
PS The link to the blog entry I meant to include:
https://blogs.oracle.com/darcy/entry/nested_inner_member_and_top
-Joe
On 1/12/2013 10:36 AM, Joe Darcy wrote:
Hi Eric,
On 1/11/2013 9:14 PM, Eric McCorkle wrote:
I got halfway through implementing a change that would synthesize
Parameter's for the static links (this for the inner classes), when it
occurred to me: is there really a case for allowing reflection on those
parameters.
Put another way,
public class Foo {
public class Bar {
int baz(int qux) { }
}
}
Should baz.getParameters() return just qux, or should it expose
Foo.this? On second thought, I can't think of a good reason why you
*want* to reflect on Foo.this.
You need to reflect on that parameter so you can call the constructor
properly using reflection :-)
Also, the logic is much simpler. You just have to figure out how deep
you are in inner classes, store that information somewhere, and offset
by that much every time a Parameter calls back to its Executable to get
information. The logic for synthesizing the this parameters is much
more complex.
Thoughts?
We may need some more help from javac to mark parameters as
synthesized or synthetic, which can be done as follow-up work. For
inner classes that are members of types, the outer this parameters are
required to be a certain way by the platform specification to make
linkage work. *However*, local and anonymous classes only have to
obey a compiler's contract with itself and are not specified. In
particular, not all such inner classes constructors even have an outer
this parameter. For example, with javac the constructor of an
anonymous class in a static initializer will *not* have an other this
parameter.
-Joe
On 01/11/13 13:27, Joe Darcy wrote:
Hi Eric,
Taking another look at the code, some extra logic / checking is needed
in cases where the number of source parameters (non-synthetic and
non-synthesized) disagrees with the number of actual parameters at a
class file level.
For example, if the single source parameter of an inner class
constructor is annotated, the annotation should be associated with the
*second* parameter since the first class file parameter is a
synthesized
constructor added by the compiler. I think generally annotations
should
not be associated with synthesized or synthetic parameters.
-Joe
On 1/11/2013 9:03 AM, Eric McCorkle wrote:
Update should be visible now.
On 01/11/13 11:54, Vitaly Davidovich wrote:
Yes that's exactly what I'm looking for as well.
Sent from my phone
On Jan 11, 2013 11:25 AM, Peter Levart peter.lev...@gmail.com
mailto:peter.lev...@gmail.com wrote:
On 01/11/2013 04:54 PM, Eric McCorkle wrote:
The webrev has been updated again.
The multiple writes to parameters have been removed, and
the
tests have
been expanded to look at inner classes, and to test
modifiers.
Please look over it again.
Hello Eric,
You still have 2 reads of volatile even in fast path. I
would do it
this way:
private Parameter[] privateGetParameters() {
Parameter[] tmp = parameters; // one and only read
if (tmp != null)
return tmp;
// Otherwise, go to the JVM to get them
tmp = getParameters0();
// If we get back nothing, then synthesize parameters
if (tmp == null) {
final int num = getParameterCount();
tmp = new Parameter[num];
for (int i = 0; i num; i++)
// TODO: is there a way to synthetically derive the
// modifiers? Probably not in the general case, since
// we'd have no way of knowing about them, but there
// may be specific cases.
tmp[i] = new Parameter(arg + i, 0, this, i);
// This avoids possible races from seeing a
// half-initialized parameters cache.
}
parameters = tmp;
return tmp;
}
Regards, Peter
Test-wise, I've got a clean run on JPRT (there were some
failures in
lambda stuff, but I've been seeing that for some time now).
On 01/10/13 21:47, Eric McCorkle wrote:
On 01/10/13 19:50, Vitaly Davidovich wrote:
Hi Eric,
Parameter.equals() doesn't need null check -
instanceof
covers that already.
Removed.
Maybe this has been mentioned already, but
personally
I'm not a fan of
null checks such as if (null == x) - I prefer the
null
on the right
hand side, but that's just stylistic.
Changed.
Perhaps I'm looking at a stale webrev but
Executable.__privateGetParameters() reads and
writes
from/to the volatile
field more
Re: Review request JDK-8004729: Parameter Reflection API
Hi Eric,
On 1/11/2013 9:14 PM, Eric McCorkle wrote:
I got halfway through implementing a change that would synthesize
Parameter's for the static links (this for the inner classes), when it
occurred to me: is there really a case for allowing reflection on those
parameters.
Put another way,
public class Foo {
public class Bar {
int baz(int qux) { }
}
}
Should baz.getParameters() return just qux, or should it expose
Foo.this? On second thought, I can't think of a good reason why you
*want* to reflect on Foo.this.
You need to reflect on that parameter so you can call the constructor
properly using reflection :-)
Also, the logic is much simpler. You just have to figure out how deep
you are in inner classes, store that information somewhere, and offset
by that much every time a Parameter calls back to its Executable to get
information. The logic for synthesizing the this parameters is much
more complex.
Thoughts?
We may need some more help from javac to mark parameters as synthesized
or synthetic, which can be done as follow-up work. For inner classes
that are members of types, the outer this parameters are required to be
a certain way by the platform specification to make linkage work.
*However*, local and anonymous classes only have to obey a compiler's
contract with itself and are not specified. In particular, not all such
inner classes constructors even have an outer this parameter. For
example, with javac the constructor of an anonymous class in a static
initializer will *not* have an other this parameter.
-Joe
On 01/11/13 13:27, Joe Darcy wrote:
Hi Eric,
Taking another look at the code, some extra logic / checking is needed
in cases where the number of source parameters (non-synthetic and
non-synthesized) disagrees with the number of actual parameters at a
class file level.
For example, if the single source parameter of an inner class
constructor is annotated, the annotation should be associated with the
*second* parameter since the first class file parameter is a synthesized
constructor added by the compiler. I think generally annotations should
not be associated with synthesized or synthetic parameters.
-Joe
On 1/11/2013 9:03 AM, Eric McCorkle wrote:
Update should be visible now.
On 01/11/13 11:54, Vitaly Davidovich wrote:
Yes that's exactly what I'm looking for as well.
Sent from my phone
On Jan 11, 2013 11:25 AM, Peter Levart peter.lev...@gmail.com
mailto:peter.lev...@gmail.com wrote:
On 01/11/2013 04:54 PM, Eric McCorkle wrote:
The webrev has been updated again.
The multiple writes to parameters have been removed, and the
tests have
been expanded to look at inner classes, and to test modifiers.
Please look over it again.
Hello Eric,
You still have 2 reads of volatile even in fast path. I would do it
this way:
private Parameter[] privateGetParameters() {
Parameter[] tmp = parameters; // one and only read
if (tmp != null)
return tmp;
// Otherwise, go to the JVM to get them
tmp = getParameters0();
// If we get back nothing, then synthesize parameters
if (tmp == null) {
final int num = getParameterCount();
tmp = new Parameter[num];
for (int i = 0; i num; i++)
// TODO: is there a way to synthetically derive the
// modifiers? Probably not in the general case, since
// we'd have no way of knowing about them, but there
// may be specific cases.
tmp[i] = new Parameter(arg + i, 0, this, i);
// This avoids possible races from seeing a
// half-initialized parameters cache.
}
parameters = tmp;
return tmp;
}
Regards, Peter
Test-wise, I've got a clean run on JPRT (there were some
failures in
lambda stuff, but I've been seeing that for some time now).
On 01/10/13 21:47, Eric McCorkle wrote:
On 01/10/13 19:50, Vitaly Davidovich wrote:
Hi Eric,
Parameter.equals() doesn't need null check - instanceof
covers that already.
Removed.
Maybe this has been mentioned already, but personally
I'm not a fan of
null checks such as if (null == x) - I prefer the
null
on the right
hand side, but that's just stylistic.
Changed.
Perhaps I'm looking at a stale webrev but
Executable.__privateGetParameters() reads and writes
from/to the volatile
field more than once. I think Peter already mentioned
that it should
use one read into a local and one write to publish the
final version
review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl
Hi This is a review request for 8006139 which adds missing methods to SQLInput/Output The webrev can be found at http://cr.openjdk.java.net/~lancea/8006139/webrev.00/ best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
