Re: Build Failure in JPRT Job
On 08/01/2013 07:30, Dan Xu wrote: David, Thanks for your reply. I saw other jobs also had the similar jprt command. I wonder why others could succeed in the build. If partial builds of jdk8/tl, ie: jdk repo only, are succeeding then the repository is probably not up to date. Alternatively, they are partial builds of the jdk repo in other forests, jdk8/awt/jdk for example. In general, partial builds are fragile and in the case of jdk8/tl then there regular flag days where you need to build langtools+jdk, can't use the langtools from a promoted build. -Alan
hg: jdk8/tl/langtools: 3 new changesets
Changeset: 38d3d1027f5a Author:mcimadamore Date: 2013-01-08 10:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/38d3d1027f5a 8005243: Restructure method check code to allow pluggable checkers Summary: Add interface to perform a method check - to be implemented by helper classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: db91d860156a Author:mcimadamore Date: 2013-01-08 10:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/db91d860156a 8005179: Cleanup Resolve.AmbiguityError Summary: Linearize nested ambiguity errors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out Changeset: d07340b61e6a Author:mcimadamore Date: 2013-01-08 10:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d07340b61e6a 8005184: Restructure DeferredAttr to allow pluggable deferred type completers Summary: Add hooks to generalize deferred type completion via custom helper objects Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
Re: Request for Review: Java SE 8 Compact Profiles
On 08/01/2013 04:55, David Holmes wrote: I've generated a fresh webrev with your changes. http://cr.openjdk.java.net/~dholmes/8004265.v2/webrev.jdk/ Looking to get the Thumbs up on the src and test changes. Thanks for updating the webrev, I can confirm that it has all of the changes that we were accumulating in jdk8/profiles. I've put a page here with additional details as to what is in (or not in) each of the builds: http://cr.openjdk.java.net/~alanb/profiles/impl_notes.html This supplements the API packages proposed in the JEP (I will update the JEP once all the Lambda work and JSR-310 is in as the contents are a bit of a moving target at this time). -Alan
Improving ThreadLocalRandom (and related classes)
When we introduced ThreadLocalRandom, we conservatively implemented it to use an actual ThreadLocal. However, as it becomes more widely used, it is worth improving the implementation by housing ThreadLocalRandom state (and related bookkeeping) in class Thread itself. This would entail three fields (16 total bytes). So I propose adding the following to class Thread: // The following three initially uninitialized fields are exclusively // managed by class java.util.concurrent.ThreadLocalRandom. /** The current seed for a ThreadLocalRandom */ long threadLocalRandomSeed; /** Probe hash value; nonzero if threadLocalRandomSeed initialized */ int threadLocalRandomProbe; /** Secondary seed isolated from public ThreadLocalRandom sequence */ int threadLocalRandomSecondarySeed; The reasons for doing it in this way are: 1. Uniformly faster access to ThreadLocalRandom state. While ThreadLocal access is normally pretty fast already, this is not only faster, it does not degrade in cases where user programs create large numbers of ThreadLocals, which may (probabilistically) cause any given access to become slower. 2. Smaller total footprint for any program using ThreadLocalRandom. Three fields require less space than boxing into a padded ThreadLocal object. As ThreadLocalRandom becomes widely used within JDK itself, this includes just about all programs. 3. Further time/space savings for java.util.concurrent ForkJoinPool, ConcurrentHashMap, LongAdder, ConcurrentSkipList, and other classes that could use this form of the unified ThreadLocalRandom bookkeeping rather than their own special-purpose ThreadLocals as they now do. Any objections? If not, I'd need the help of someone permitted to paste the above into class Thread, review, and and commit. -Doug
Re: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)
On 1/8/13 5:13 AM, Mandy Chung wrote:
Hi Daniel,
I also agree with option 3 be the best option among them. Joe's
suggestion to throw an exception if factoryId is not the base service
type is good so that any existing application depending on that behavior
will catch this change. Are you going to revise the spec - there is
statement saying that the newFactory method is the same behavior as
newInstance method which is weakly specified.
139* No changes in behavior are defined by this replacement method
relative
140* to the deprecated method.
It'd be good to add some tests to cover these APIs if there is none.
Otherwise, the change looks good.
Mandy
Right - thanks Mandy.
I've clarified the spec. I also documented an additional step, which
was done by the implementation but not documented - which is that
the stream factory will also look up for properties in jaxp.properties
if stax.properties was not found.
webrev:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.03/
I have generated a spec diff for easier reading of the doc changes:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/specdiff.03/overview-summary.html
regards,
-- daniel
On 1/7/2013 2:34 AM, Daniel Fuchs wrote:
Thanks Joe.
To make things clear I have pushed a revised webrev with solution 3.
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.02.3/
The lines of interest are in FactoryFinder.java - right hand side:
267 if (type.getName().equals(factoryId)) {
268 // Try Jar Service Provider Mechanism
269 final T provider = findServiceProvider(type);
270 if (provider != null) {
271 return provider;
272 }
273 } else {
274 // We're in the case where a 'custom' factoryId was
provided,
275 // and in every case where that happens, we expect that
276 // fallbackClassName will be null.
277 assert fallbackClassName == null;
278 }
regards,
-- daniel
On 1/4/13 7:51 PM, Joe Wang wrote:
Hi Daniel,
Yes, I agree with 3. As I said before, we should return an error if
factoryId != type.getName() since it indicates a configuration error.
Scenario 4 does exist, but it's beyond the current spec. Such an impl
should not use the default API.
The StAX spec is not always clear. My interpretation of the definition
of factoryId to be the same as a property name is that the author
basically was saying that it's equivalent to a name as in a property,
not the value, therefore different from the DOM/SAX API -- a bad
choice I would think.
Thanks,
Joe
On 1/4/2013 6:31 AM, Daniel Fuchs wrote:
Hi guys,
Happy new year to you all! And apologies for this long email :-)
I think we still haven't converged on this issue in
javax.xml.stream - so let me make a recap.
The issue is for the newInstance/newFactory methods
that take a factoryId parameter, in the factories for
the javax.xml.stream package:
[
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.01/
FactoryFinder.java: line 267-268 right hand side. ]
recap of the issue:
---
In case the provided factoryId did not correspond to any
System/JAXP/StAX property, the old code used to look
for a service in META-INF/services using the factoryId as the
name of the file for looking up the implementation class.
In case factoryId was not the same as the base service
class (or a subclass of it) it still would have worked
although it went in contradiction to the Jar Specification
mentioned in the javadoc, since the Jar Specification clearly
states that the file name should be the fully qualified name
of the base service class.
Since we're going to replace the code that looked up for
a service in META-INF with a call to ServiceLoader, we can
no longer fully preserve that old behavior, because ServiceLoader
only takes a base service class (and no arbitrary file name).
what choices do we have?
The question is therefore how we want to change this.
I think we have 4 (exclusive) possibilities.
In the case where a factoryId is provided, but no
System/JAXP/StAX property by that name has been found,
we could choose to either:
1. Always call ServiceLoader.load(type) where type is the
service base class.
2. Never call ServiceLoader.load(type)
3. Only call ServiceLoader.load(type) when the provided
factoryId is equal to type.getName()
4. If factoryId is equal to type.getName(), call
ServiceLoader.load(type), otherwise,
attempt to load factoryId as a class - and if that
class is a subclass of 'type' then call
ServiceLoader.load for that subclass.
pros cons:
Here is a list of pros cons for each of these options:
1. is the naive implementation I originally proposed.
Pros:
- P1.1: simple
- P1.2: no change in behavior if factoryId == type.getName()
Cons:
- C1.1: may find no provider when the
Re: Fwd: OpenJDK builds: Ant build issues with jdk (netbeans) sub-projects - awt2d, j2se and jarzip
Hi Mani, nb-projects-...@openjdk.java.net should be the right place, but there is little trafic. This keeps me wondering too since years, as NetBeans is an Oracle Product. It's a mystery why it seems so hard to have NetBeans working for JDK developement workflow. So I think it's OK to additionally put your question here in core-libs. -Ulf Am 08.01.2013 00:21, schrieb Mani Sarkar: Hi, I have been recommended to post my below query to your mailing list, if it is the right place to post. If not could you recommend who would be best placed to answer the below questions. I couldn't find an appropriate mailing list for 'jarzip' (as it is part of langtools) - any suggestions? It would be great if you could answer my query about it too. Thanks. Regards, Mani On 01/05/2013 04:05 PM, Mani Sarkar wrote: Hi all, I have made some progress with the below three sub-projects, and have successfully built jarzip. But still get new error messages with awt2d and j2se. I answered my own question about the -source 8, its basically expecting the images/j2sdk-image to be assigned to the respective ALT_... variables via the make.options property in build.properties for all three projects. Unfortunately I wasn't able to build swing via the .../javax/swing/ folder where the required make file(s) are present. But my other queries still stand, if you can throw some light on them, it would be help make progress with these builds using the new build system. Thanks. Regards, Mani On Sat, Jan 5, 2013 at 12:39 AM, Mani Sarkar sadhak...@gmail.com wrote: Hi All, I have furthered my pursuits with building *OpenJDK projects *by building the JDK sub-projects like swing, etc... but came across issues with building 3 different projects which I wasn't able to build due configuration issues. These sub-projects are located under the netbeans subfolder under the .../jdk/make/ folder. They all are getting compiled for version 8 with the below args (which is leading to a build failure): -source 8 -target 8 *jdk/awt2d* https://github.com/**neomatrix369/BuildHelpers/**blob/master/** EclipseProjectsForOpenJDK/**Logs/jdk/awt2d/awt2dAntBuild.**loghttps://github.com/neomatrix369/BuildHelpers/blob/master/EclipseProjectsForOpenJDK/Logs/jdk/awt2d/awt2dAntBuild.log *jdk/j2se* https://github.com/**neomatrix369/BuildHelpers/**blob/master/** EclipseProjectsForOpenJDK/**Logs/jdk/j2se/j2seAntBuild.loghttps://github.com/neomatrix369/BuildHelpers/blob/master/EclipseProjectsForOpenJDK/Logs/jdk/j2se/j2seAntBuild.log *jdk/jarzip* https://github.com/**neomatrix369/BuildHelpers/**blob/master/** EclipseProjectsForOpenJDK/**Logs/jdk/jarzip/**jarzipAntBuild.loghttps://github.com/neomatrix369/BuildHelpers/blob/master/EclipseProjectsForOpenJDK/Logs/jdk/jarzip/jarzipAntBuild.log Where is this version configuration set for these projects, that I can change either through file changes or alternative build.properties setting changes? My other question is why are there no make files available for the jdk sub-projects (i.e. *awt2d, j2se,* etc...) except for under * javax/swing* has make files to build this project instead Ant build.xml files are available. Is it possible to hook these ant files with the new build system, instead of only being able to build the sub-projects via the old build system (using the ALT_... variables via make.options). Thanks. Regards, mani -- Twitter: @theNeomatrix369 Blog: http://neomatrix369.wordpress.**comhttp://neomatrix369.wordpress.com http://neomatrxi369.**wordpress.com http://neomatrxi369.wordpress.com *Don't chase success, rather aim for Excellence, and success will come chasing after you!*
hg: jdk8/tl/langtools: 8005167: execution time of combo tests in javac should be improved
Changeset: 954541f13717 Author:vromero Date: 2013-01-08 13:47 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/954541f13717 8005167: execution time of combo tests in javac should be improved Reviewed-by: jjg, jjh ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T7093325.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java + test/tools/javac/lib/JavacTestingAbstractThreadedTest.java ! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java ! test/tools/javac/varargs/7042566/T7042566.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java
Re: Improving ThreadLocalRandom (and related classes)
On 01/08/2013 12:05 PM, Doug Lea wrote: 1. Uniformly faster access to ThreadLocalRandom state. While ThreadLocal access is normally pretty fast already, this is not only faster, it does not degrade in cases where user programs create large numbers of ThreadLocals, which may (probabilistically) cause any given access to become slower. One random thought. Linux x86 has very fast access to thread local variables: it's just a segment prefix on a load instruction. I wonder if the JVM could utilize something like this and so improve performance for thread locals that don't require non-null initial values. This would be better than piling everything into Thread's state... Andrew.
Re: Improving ThreadLocalRandom (and related classes)
On 01/08/13 08:43, Andrew Haley wrote: One random thought. Linux x86 has very fast access to thread local variables: it's just a segment prefix on a load instruction. I wonder if the JVM could utilize something like this and so improve performance for thread locals that don't require non-null initial values. Thanks. Yes, I've had discussions with various people over the years about somehow exploiting native thread-local support for simple scalars. I don't think there is a great scheme to be had here though. Problems include (1) fixed arena sizes on some/most platforms. (2) no good way to coordinate slot-grabbing with native uses (3) no good way to relinquish (4) no good emulation scheme for systems without support But mostly: The space for permanent thread-locals needs to be placed somewhere; why not choose the place that presents the fewest logistics problems? Note that class java.lang.Thread is only the visible tip of the iceberg of per-thread storage on systems. so adding 16bytes is all but undetectable. -Doug
Review Request: 8005856: build-infra: Remove special handling of base module classes header generation
Five classes which in jigsaw will be located in the base module currently have their native headers generated in a special way (explicitly with javah). This was because the base module could not be made dependent on the compiler module where the annotation javax.tools.annotation.GenerateNativeHeader is. Now there is a new annotation on fields, java.lang.annotation.Native, that can be used for these classes. Since this change touches java files, I'm adding core-libs to the review. Original change in build-infra was made by Fredrik Ohrstrom. http://cr.openjdk.java.net/~erikj/8005856/webrev.jdk.01/ /Erik
Re: Review Request: 8005856: build-infra: Remove special handling of base module classes header generation
On 08/01/2013 14:07, Erik Joelsson wrote: Five classes which in jigsaw will be located in the base module currently have their native headers generated in a special way (explicitly with javah). This was because the base module could not be made dependent on the compiler module where the annotation javax.tools.annotation.GenerateNativeHeader is. Now there is a new annotation on fields, java.lang.annotation.Native, that can be used for these classes. Since this change touches java files, I'm adding core-libs to the review. Original change in build-infra was made by Fredrik Ohrstrom. http://cr.openjdk.java.net/~erikj/8005856/webrev.jdk.01/ /Erik This looks good to me. -Alan
Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder
On 01/07/2013 08:07 PM, Joe Darcy wrote:
Hello,
I had a question about how the double accumulation logic was intended
to be used. I've taken a quick look at the code and it uses
straightforward sum = sum + nextValue code to compute the double
sum. Summing doubles values with code numerical accuracy is
surprisingly tricky and if the DoubleAccumulator code is meant for
wide use, I'd recommend using instead some form of compensated summation:
http://en.wikipedia.org/wiki/Kahan_summation_algorithm
Hello Joe,
It's very hard to program such algorithm in Java. Guess what prints the
following code:
double x = 1.0E100;
double a = 1d;
double y = x + a;
double diff = y - x;
double c = a - diff;
System.out.println(diff);
System.out.println(c);
Do you have any idea how to do that (still using local variables)?
Regards, Peter
Thanks,
-Joe
On 1/5/2013 10:10 AM, Chris Hegarty wrote:
As part of JEP 155 we are proposing to add the following public
classes to support Scalable Updatable Variables, DoubleAccumulator,
DoubleAdder, LongAccumulator and LongAdder.
These have been written by Doug Lea, with assistance from members of
the former JCP JSR-166 Expert Group.
Webrev and javadoc are at:
http://cr.openjdk.java.net/~chegar/8005311/ver.00/
Since Doug is the author, I am taking a reviewer/sponsor role.
Here are my initial comments.
- There are various places in DoubleAccmulator where there are broken
links to #sum ( I think it is just a cut'n'paste error ). These
should be #get.
- Accumulators
{@link #get} may read somewhat better as {@link #get current
value} ??
- Accumulators
Does the 'identity' value need further explanation?
Note: There is one minor change to the implementation. Currently in
the jdk8 repo j.u.f.DoubleBinaryOperator defines operateAsDouble.
This method has been renamed to applyAsDouble in the lambda/lambda
repo. When these changes are sync'ed from lambda/lambda this can be
reverted. A similar comment has been added to the code.
-Chris.
Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder
On 01/05/2013 07:10 PM, Chris Hegarty wrote:
As part of JEP 155 we are proposing to add the following public
classes to support Scalable Updatable Variables, DoubleAccumulator,
DoubleAdder, LongAccumulator and LongAdder.
These have been written by Doug Lea, with assistance from members of
the former JCP JSR-166 Expert Group.
Hello Doug,
These are very interesting and useful classes already as they are. They
might be also used for other unintended purposes like scalable random
generators, or unique identifier generators if their API would expose
some more info. For example, I did an experiment and patched the code
paths used in LongAccumulator so that:
- accumulate(long x) returns the post-modification value of the modified
cell or base (the returned value of the function that was used to update
the state)
- the accumulator function is always called for initial allocations of
cells (with identity value as 1st argument, like when accumulating on
the base) - the original code optimizes this situation and just installs
the parameter x into the cell.
With this modified API and a little copy-and-paste, I could quickly
assemble the following MultiThreadedRandom:
public class MultiThreadedRandom extends Random {
private static final long multiplier = 0x5DEECE66DL;
private static final long addend = 0xBL;
private static final long mask = (1L 48) - 1;
private static final AtomicLong seedUniquifier
= new AtomicLong(8682522807148012L);
private static final LongSupplier defaultSeedSupplier = () - {
// L'Ecuyer, Tables of Linear Congruential Generators of
// Different Sizes and Good Lattice Structure, 1999
for (; ; ) {
long current = seedUniquifier.get();
long next = current * 181783497276652981L;
if (seedUniquifier.compareAndSet(current, next))
return next;
}
};
private final LongAccumulator rnd;
public MultiThreadedRandom() {
this(defaultSeedSupplier);
}
public MultiThreadedRandom(final LongSupplier seedSupplier) {
super(0L); // ignored
Objects.requireNonNull(seedSupplier);
this.rnd = new LongAccumulator(
(seed, _ignore) - {
if (seed == 0L) seed = (seedSupplier.getAsLong() ^
multiplier) mask;
return (seed * multiplier + addend) mask;
},
0L
);
}
public void setSeed(long seed) {
if (rnd != null)
throw new UnsupportedOperationException();
}
@Override
protected int next(int bits) {
long nextseed = rnd.accumulate(0L);
return (int) (nextseed (48 - bits));
}
}
...which has great scalability, although it is about 3x slower then
TreadLocalRandom.current().next()...
I'm also thinking about what would be possible to do with DoubleAdder it
it had a method like getAndAdd(double x) which returned the
pre-modification state of the cell/base. It might be possible to use two
DoubleAdders to devise a more accurate adder for example:
public class MyDoubleAdder {
private final DoubleAdder primary = new DoubleAdder();
private final DoubleAdder secondary = new DoubleAdder();
public void add(double x) {
double prev = primary.getAndAdd(x);
double next = prev + x;
double diff = next - prev;
double c = x - diff;
secondary.add(c);
}
public double sum()
{
return primary.sum() + secondary.sum();
}
}
Regards, Peter
P.S. Here's a patch I used:
diff --git a/jdk/src/java/util/concurrent/atomic/LongAccumulator.java
b/jdk/src/java/util/concurrent/atomic/LongAccumulator.java
index 720722e..e84b9b3 100644
--- a/jdk/src/java/util/concurrent/atomic/LongAccumulator.java
+++ b/jdk/src/java/util/concurrent/atomic/LongAccumulator.java
@@ -86,8 +86,9 @@ public class LongAccumulator extends Striped64
implements Serializable {
* Updates with the given value.
*
* @param x the value
+ * @return the returned value of the accumulator function that was
used to update the state of this accumulator
*/
-public void accumulate(long x) {
+public long accumulate(long x) {
Cell[] as; long b, v, r; CellHashCode hc; Cell a; int m;
if ((as = cells) != null ||
(r = function.applyAsLong(b = base, x)) != b
!casBase(b, r)) { // ## rename when JDK8 syncs with lambda, applyAsLong
@@ -98,8 +99,9 @@ public class LongAccumulator extends Striped64
implements Serializable {
!(uncontended =
(r = function.applyAsLong(v = a.value, x)) == v ||
// ## rename when JDK8 syncs with lambda, applyAsLong
a.cas(v, r)))
-longAccumulate(x, hc, function, uncontended);
+r = longAccumulate(x, hc, identity, function, uncontended);
}
+return r;
}
/**
diff --git
Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder
On 01/08/2013 03:38 PM, Peter Levart wrote:
On 01/07/2013 08:07 PM, Joe Darcy wrote:
Hello,
I had a question about how the double accumulation logic was intended
to be used. I've taken a quick look at the code and it uses
straightforward sum = sum + nextValue code to compute the double
sum. Summing doubles values with code numerical accuracy is
surprisingly tricky and if the DoubleAccumulator code is meant for
wide use, I'd recommend using instead some form of compensated
summation:
http://en.wikipedia.org/wiki/Kahan_summation_algorithm
Hello Joe,
It's very hard to program such algorithm in Java. Guess what prints
the following code:
double x = 1.0E100;
double a = 1d;
double y = x + a;
double diff = y - x;
double c = a - diff;
System.out.println(diff);
System.out.println(c);
Do you have any idea how to do that (still using local variables)?
Regards, Peter
Disregard this question. I thought I saw it reversed...
Regards, Peter
Thanks,
-Joe
On 1/5/2013 10:10 AM, Chris Hegarty wrote:
As part of JEP 155 we are proposing to add the following public
classes to support Scalable Updatable Variables, DoubleAccumulator,
DoubleAdder, LongAccumulator and LongAdder.
These have been written by Doug Lea, with assistance from members of
the former JCP JSR-166 Expert Group.
Webrev and javadoc are at:
http://cr.openjdk.java.net/~chegar/8005311/ver.00/
Since Doug is the author, I am taking a reviewer/sponsor role.
Here are my initial comments.
- There are various places in DoubleAccmulator where there are broken
links to #sum ( I think it is just a cut'n'paste error ). These
should be #get.
- Accumulators
{@link #get} may read somewhat better as {@link #get current
value} ??
- Accumulators
Does the 'identity' value need further explanation?
Note: There is one minor change to the implementation. Currently in
the jdk8 repo j.u.f.DoubleBinaryOperator defines operateAsDouble.
This method has been renamed to applyAsDouble in the lambda/lambda
repo. When these changes are sync'ed from lambda/lambda this can be
reverted. A similar comment has been added to the code.
-Chris.
Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder
On 01/08/13 10:01, Peter Levart wrote: - accumulate(long x) returns the post-modification value of the modified cell or base (the returned value of the function that was used to update the state) To avoid what would be a serious and common usage error (people treating the return value as if it were the aggregate result), this would need to be exposed only in a suitably-name protected method. OK? - the accumulator function is always called for initial allocations of cells (with identity value as 1st argument, like when accumulating on the base) - the original code optimizes this situation and just installs the parameter x into the cell. Good idea; thanks. I see that this tiny and cheap change would just barely widen applicability. -Doug
Re: Improving ThreadLocalRandom (and related classes)
Doug, I have no objection as such to adding certain fields to j.l.Thread to support faster ThreadLocalRandom. Maybe it would help to see how they are to be used? Given, 1 and 2 below ( I'm not sure about 3 ), would having a direct reference from j.l.Thread to ThreadLocalRandom (rather than using ThreadLocal) resolve these problems? -Chris. On 01/08/2013 12:05 PM, Doug Lea wrote: When we introduced ThreadLocalRandom, we conservatively implemented it to use an actual ThreadLocal. However, as it becomes more widely used, it is worth improving the implementation by housing ThreadLocalRandom state (and related bookkeeping) in class Thread itself. This would entail three fields (16 total bytes). So I propose adding the following to class Thread: // The following three initially uninitialized fields are exclusively // managed by class java.util.concurrent.ThreadLocalRandom. /** The current seed for a ThreadLocalRandom */ long threadLocalRandomSeed; /** Probe hash value; nonzero if threadLocalRandomSeed initialized */ int threadLocalRandomProbe; /** Secondary seed isolated from public ThreadLocalRandom sequence */ int threadLocalRandomSecondarySeed; The reasons for doing it in this way are: 1. Uniformly faster access to ThreadLocalRandom state. While ThreadLocal access is normally pretty fast already, this is not only faster, it does not degrade in cases where user programs create large numbers of ThreadLocals, which may (probabilistically) cause any given access to become slower. 2. Smaller total footprint for any program using ThreadLocalRandom. Three fields require less space than boxing into a padded ThreadLocal object. As ThreadLocalRandom becomes widely used within JDK itself, this includes just about all programs. 3. Further time/space savings for java.util.concurrent ForkJoinPool, ConcurrentHashMap, LongAdder, ConcurrentSkipList, and other classes that could use this form of the unified ThreadLocalRandom bookkeeping rather than their own special-purpose ThreadLocals as they now do. Any objections? If not, I'd need the help of someone permitted to paste the above into class Thread, review, and and commit. -Doug
Re: Improving ThreadLocalRandom (and related classes)
On 01/08/13 11:07, Chris Hegarty wrote: Doug, I have no objection as such to adding certain fields to j.l.Thread to support faster ThreadLocalRandom. Maybe it would help to see how they are to be used? One use that reminded me that I ought to take this issue out of background and propose it was the the discussion surrounding the possible us of ThreadLocalRandom with HashMaps. It would be great if the 99% of all the uses of Random that could sensibly use ThreadLocalRandom did so. Improving the incentives to use it wouldn't hurt. Given, 1 and 2 below ( I'm not sure about 3 ), would having a direct reference from j.l.Thread to ThreadLocalRandom (rather than using ThreadLocal) resolve these problems? Yes, this is the Plan-B approach. It seems a little worse. For completeness, I should have mentioned it: By just keeping an initially-null pointer to a ThreadLocalRandom, you can reduce impact on class Thread itself from 16 to 4/8 bytes (depending on 32 vs 64bit pointers). However, the actual ThreadLocalRandom object is padded to avoid memory contention (which wouldn't be necessary or useful if already embedded withing Thread). It also adds (a tiny bit) to preventable GC load to have a pointer in Thread that is never collectable and must be scanned even if never used. While the decision depends in part on the probability of use, I can't think of a good reason to recommend this approach. -Doug
Re: Improving ThreadLocalRandom (and related classes)
On 01/08/13 11:07, Chris Hegarty wrote: Doug, I have no objection as such to adding certain fields to j.l.Thread to support faster ThreadLocalRandom. Maybe it would help to see how they are to be used? Sorry, it just occurred to me that you surely meant: how would these Thread fields be used in ThreadLocalRandom. here's the basic plan: 1. There is a singleton TLR that is always returned by TLR.current after first checking (via nonzero probe) if initialized for this thread. 2. On a call to next() etc, this object accesses and updates threadLocalRandomSeed using Unsafe (to bypass access control). -Doug
Re: Could you sponsor another simple fix?
The correct list is core-libs-dev@openjdk.java.net I will be the sponsor for this change. -Sherman On 01/08/2013 10:38 AM, Coleen Phillimore wrote: Hi Ioi, I copied it to cr.openjdk.java.net/~coleenp/8005466_zip_util_001 I think the mailing list is jdk8-...@openjdk.java.net. I don't know about jdk8. Since it's a tools/libraries fix, it should be relative to the TL repository (not sure if your fix is). I'm apparently reviewer on jdk8 and allowed to sponsor changes to jdk8 but I'd prefer if someone like Alan Bateman who actually works on the jdk do this. This fix seems cool. Thanks, Coleen On 01/08/2013 11:43 AM, Ioi Lam wrote: Coleen, https://jbs.oracle.com/bugs/browse/JDK-8005466?focusedCommentId=13288645#comment-13288645 http://javaweb.us.oracle.com/~iklam/webrev/8005466_zip_util_001/ http://javaweb.us.oracle.com/%7Eiklam/webrev/8005466_zip_util_001/ A one-liner would save about 540KB with Eclipse on 64-bit VMs. BTW, which mailing list should this be sent to? hotspot-dev@openjdk? Karen, would it be possible for this to get into JDK8? Thanks - Ioi
Re: Could you sponsor another simple fix?
Thanks! This change looks very good to me - why did we the maintainers of zip_util never notice it? It's worth a later backport to jdk7 as well. On Tue, Jan 8, 2013 at 10:53 AM, Xueming Shen xueming.s...@oracle.comwrote: The correct list is core-libs-dev@openjdk.java.net I will be the sponsor for this change. -Sherman On 01/08/2013 10:38 AM, Coleen Phillimore wrote: Hi Ioi, I copied it to cr.openjdk.java.net/~coleenp/**8005466_zip_util_001http://cr.openjdk.java.net/~coleenp/8005466_zip_util_001 I think the mailing list is jdk8-...@openjdk.java.net. I don't know about jdk8. Since it's a tools/libraries fix, it should be relative to the TL repository (not sure if your fix is). I'm apparently reviewer on jdk8 and allowed to sponsor changes to jdk8 but I'd prefer if someone like Alan Bateman who actually works on the jdk do this. This fix seems cool. Thanks, Coleen On 01/08/2013 11:43 AM, Ioi Lam wrote: Coleen, https://jbs.oracle.com/bugs/**browse/JDK-8005466?** focusedCommentId=13288645#**comment-13288645https://jbs.oracle.com/bugs/browse/JDK-8005466?focusedCommentId=13288645#comment-13288645 http://javaweb.us.oracle.com/~**iklam/webrev/8005466_zip_util_**001/http://javaweb.us.oracle.com/~iklam/webrev/8005466_zip_util_001/ http://javaweb.us.oracle.com/**%7Eiklam/webrev/8005466_zip_**util_001/http://javaweb.us.oracle.com/%7Eiklam/webrev/8005466_zip_util_001/ A one-liner would save about 540KB with Eclipse on 64-bit VMs. BTW, which mailing list should this be sent to? hotspot-dev@openjdk? Karen, would it be possible for this to get into JDK8? Thanks - Ioi
Re: Review Request: 8005856: build-infra: Remove special handling of base module classes header generation
Looks good. -kto On Jan 8, 2013, at 6:07 AM, Erik Joelsson wrote: Five classes which in jigsaw will be located in the base module currently have their native headers generated in a special way (explicitly with javah). This was because the base module could not be made dependent on the compiler module where the annotation javax.tools.annotation.GenerateNativeHeader is. Now there is a new annotation on fields, java.lang.annotation.Native, that can be used for these classes. Since this change touches java files, I'm adding core-libs to the review. Original change in build-infra was made by Fredrik Ohrstrom. http://cr.openjdk.java.net/~erikj/8005856/webrev.jdk.01/ /Erik
hg: jdk8/tl/jdk: 8002306: (se) Selector.open fails if invoked with thread interrupt status set [win]
Changeset: d29a7ce28189 Author:dxu Date: 2013-01-08 20:37 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d29a7ce28189 8002306: (se) Selector.open fails if invoked with thread interrupt status set [win] Reviewed-by: alanb ! src/windows/classes/sun/nio/ch/PipeImpl.java + test/java/nio/channels/Pipe/PipeInterrupt.java
hg: jdk8/tl/jdk: 4 new changesets
Changeset: 46e6a4b7ca26 Author:valeriep Date: 2013-01-07 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46e6a4b7ca26 6996769: support AEAD cipher Summary: Added implementation for GCM mode under AES cipher Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherTextStealing.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java + src/share/classes/com/sun/crypto/provider/GCMParameters.java + src/share/classes/com/sun/crypto/provider/GCTR.java + src/share/classes/com/sun/crypto/provider/GHASH.java + src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/spec/GCMParameterSpec.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512524.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512704.java ! test/com/sun/crypto/provider/Cipher/AES/Test4517355.java ! test/com/sun/crypto/provider/Cipher/AES/Test4626070.java + test/com/sun/crypto/provider/Cipher/AES/TestGCMKeyAndIvCheck.java + test/com/sun/crypto/provider/Cipher/AES/TestKATForGCM.java ! test/javax/crypto/Cipher/GCMAPI.java Changeset: 5333a4c8cade Author:valeriep Date: 2013-01-07 14:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5333a4c8cade Merge Changeset: 3c5a62290939 Author:valeriep Date: 2013-01-08 11:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c5a62290939 8004044: Lazily instantiate SunJCE.RANDOM Summary: Replace the static initialization of SunJCE.RANDOM object w/ lazy initialization Reviewed-by: mchung ! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/ISO10126Padding.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/share/classes/com/sun/crypto/provider/PBES2Core.java ! src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java Changeset: 9b6a29cb04ac Author:valeriep Date: 2013-01-08 13:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b6a29cb04ac Merge
JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries
Hello, As discussed over on one of the Project Lambda lists [1], we're adding an interface type to the platform to explicitly mark interface types as being functional interfaces suitable for use in lambda expressions. Please review the addition of this new type: http://cr.openjdk.java.net/~darcy/8005298.0/ Follow-up work will add @FunctionalInterface annotations to appropriate platform classes. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December/000846.html
Re: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries
Perhaps {@code} around java.lang.Object.
The default method and overriding Object method sentences could perhaps be said
more simply:
{@linkplain java.lang.reflect.Method#isDefault() default methods} in
interfaces do provide a method implementation and are not considered abstract.
Interface methods which match methods of java.lang.Object are not considered
abstract because an implementation (from java.lang.Object) is always available.
Mostly it's enough to say that they aren't abstract. The part about abstract
method count is superfluous.
@jls ref for default methods.
@jls ref for methods of Object.
On Jan 8 2013, at 13:24 , Joe Darcy wrote:
Hello,
As discussed over on one of the Project Lambda lists [1], we're adding an
interface type to the platform to explicitly mark interface types as being
functional interfaces suitable for use in lambda expressions. Please review
the addition of this new type:
http://cr.openjdk.java.net/~darcy/8005298.0/
Follow-up work will add @FunctionalInterface annotations to appropriate
platform classes.
Thanks,
-Joe
[1]
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December/000846.html
Re: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries
Looks good now.
Mike
On Jan 8 2013, at 14:43 , Joe Darcy wrote:
PS The updated webrev is
http://cr.openjdk.java.net/~darcy/8005298.1/
Thanks,
-Joe
On 01/08/2013 02:00 PM, Joe Darcy wrote:
Hi Mike,
On 01/08/2013 01:49 PM, Mike Duigou wrote:
Perhaps {@code} around java.lang.Object.
Agreed.
The default method and overriding Object method sentences could perhaps be
said more simply:
{@linkplain java.lang.reflect.Method#isDefault() default methods} in
interfaces do provide a method implementation and are not considered
abstract.
Interface methods which match methods of java.lang.Object are not
considered abstract because an implementation (from java.lang.Object) is
always available.
Mostly it's enough to say that they aren't abstract. The part about
abstract method count is superfluous.
Okay; rewritten as:
* Conceptually, a functional interface has exactly one abstract
* method. Since {@linkplain java.lang.reflect.Method#isDefault()
* default methods} have an implementation, they are not abstract. If
* an interface declares an abstract method overriding one of the
* public methods of {@code java.lang.Object}, that also does
* emnot/em count toward the interface's abstract method count
* since any implementation of the interface will have an
* implementation from {@code java.lang.Object} or elsewhere.
@jls ref for default methods.
That is actually included in the draft text of 9.4.3 and so is covered by
* @jls 9.4.3 Interface Method Body
@jls ref for methods of Object.
That is a good addition; I'll include
* @jls 4.3.2. The Class Object
Thanks,
-Joe
On Jan 8 2013, at 13:24 , Joe Darcy wrote:
Hello,
As discussed over on one of the Project Lambda lists [1], we're adding an
interface type to the platform to explicitly mark interface types as being
functional interfaces suitable for use in lambda expressions. Please
review the addition of this new type:
http://cr.openjdk.java.net/~darcy/8005298.0/
Follow-up work will add @FunctionalInterface annotations to appropriate
platform classes.
Thanks,
-Joe
[1]
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December/000846.html
hg: jdk8/tl/jdk: 8005298: Add FunctionalInterface type to the core libraries
Changeset: ac5fd681a7a2 Author:darcy Date: 2013-01-08 16:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac5fd681a7a2 8005298: Add FunctionalInterface type to the core libraries Reviewed-by: mduigou + src/share/classes/java/lang/FunctionalInterface.java
Re: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86
Hi Vladimir, encodeArray can be made static. Also, what's the purpose of overflow flag? Once you detect overflow can't you simply return the overflow result? What's the key piece that allows jit to generate better code? Is it the encodeArray which is nice, small, and isolated? Thanks Sent from my phone On Jan 8, 2013 6:18 PM, Vladimir Kozlov vladimir.koz...@oracle.com wrote: http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrevhttp://cr.openjdk.java.net/~kvn/6896617_jdk/webrev Move encoding loop into separate method for which VM will use intrinsic on x86. I want to get agreement on this jdk change before I submit VM part. This gives +1.6% performance improvement on SPECjAppServer2004 on x86. Note, even without intrinsic (on other platforms) JIT will produce better code for this loop. Thanks, Vladimir
Re: Build Failure in JPRT Job
I'm not talking about JPRT build. I fetched all tl8 repos and do a full build, the jdeps command runs. Then I use this build as ALT_JDK_IMPORT_PATH to do a partial images build in jdk/make still shows com/sun/tools/jdeps : no such file or directory What am I missing here? Thanks Max On 01/08/2013 05:07 PM, Alan Bateman wrote: On 08/01/2013 07:30, Dan Xu wrote: David, Thanks for your reply. I saw other jobs also had the similar jprt command. I wonder why others could succeed in the build. If partial builds of jdk8/tl, ie: jdk repo only, are succeeding then the repository is probably not up to date. Alternatively, they are partial builds of the jdk repo in other forests, jdk8/awt/jdk for example. In general, partial builds are fragile and in the case of jdk8/tl then there regular flag days where you need to build langtools+jdk, can't use the langtools from a promoted build. -Alan
Re: Request for Review: Java SE 8 Compact Profiles
On Jan 8, 2013, at 12:02 AM, David Holmes wrote: http://cr.openjdk.java.net/~dholmes/8004265.v2/webrev.jdk/ Alan - I reviewed the new webrev and looks good. To follow up the comment about invalid profile attribute value: On 1/3/2013 11:54 PM, Alan Bateman wrote: L820: An empty Profile attribute is invalidand Version.supportsProfile returns false if requiredProfile parameter is empty even if the runtime is a full JRE. This is fine but I was wondering if the exception message can indicate if the attribute value is invalid to help diagnosis. We could although I'm not sure how this could arise (as you can't set an empty profile name with the p option, and the m option to add/update a manifest also disallows empty values). Looks like the jar tool -m option allows an entry with a space Profile: (a space following :) - an existing bug then. There may be other implementation to create a jar file that doesn't do the check though. sun.tools.jar.Main It would be helpful if the jar tool checks if the input profile name to the -p option is valid and outputs error. I considered this when updating the jar tool but decided at the time that it shouldn't know about the profile names. It would be easy to do of course. I see no issue with the jar tool to know about the profile names as they will be standard and part of the platform. Having the jar tool to validate the profile name will help catch mistake at packaging time. This is minor and I'm fine to revisit this in the future. Mandy
