This is a good find and the change looks good to me.
cc'ing Ioi so that he knows he has a sponsor.
-Alan.
On 08/01/2013 18:53, Xueming Shen wrote:
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
Aleksey,
Not sure where this is now but FYI you needed two CRs for this: one for
hotspot and one for the JDK. They have different target versions (hs25
vs 8) and depending on the path you use to integrate could end up in
different builds - hence distinct CRs for accurate tracking purposes.
On 01/08/2013 08:33 PM, Doug Lea wrote:
However, the actual ThreadLocalRandom object is padded to avoid
memory contention (which wouldn't be necessary or useful if already
embedded withing Thread).
I'm tempted to disagree. While it is true most of the callers are
accessing Thread in the
Thanks, David.
On 01/09/2013 02:55 PM, David Holmes wrote:
Not sure where this is now but FYI you needed two CRs for this: one for
hotspot and one for the JDK. They have different target versions (hs25
vs 8) and depending on the path you use to integrate could end up in
different builds -
Am 09.01.2013 01:10, schrieb Vitaly Davidovich:
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
On 01/08/2013 08:07 PM, Chris Hegarty wrote:
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?
I have no objections for this as well. Submitted
CR 8005926: Merge ThreadLocalRandom state
On 09/01/2013 11:10, Aleksey Shipilev wrote:
On 01/08/2013 08:07 PM, Chris Hegarty wrote:
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?
I have no objections for this as well.
On 01/09/13 06:13, Chris Hegarty wrote:
I think the complete set of changes, including the changes to ThreadLocalRandom,
should be pushed at the same time.
OK. I will try bootstrap up an environment where I can fully
adapt and test all at the same time.
-Doug
On 01/09/2013 03:13 PM, Chris Hegarty wrote:
On 09/01/2013 11:10, Aleksey Shipilev wrote:
On 01/08/2013 08:07 PM, Chris Hegarty wrote:
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?
Am 09.01.2013 01:10, schrieb Vitaly Davidovich:
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
Another tweak:
168 char[] sa = src.array();
169
On 01/09/13 05:55, Aleksey Shipilev wrote:
On 01/08/2013 08:33 PM, Doug Lea wrote:
However, the actual ThreadLocalRandom object is padded to avoid
memory contention (which wouldn't be necessary or useful if already
embedded withing Thread).
I'm tempted to disagree. While it is true most of
Good stuff.
On 01/07/2013 02:46 AM, David Holmes wrote:
http://cr.openjdk.java.net/~dholmes/8005232/webrev/
Sorry for obnoxious first-time reviewer questions:
a) I think the CAS loop in newReflectionData() is misleading in its
reuse of the parameters. Can we instead inline it? Or, can we read
On 01/09/2013 04:07 PM, Doug Lea wrote:
On 01/09/13 05:55, Aleksey Shipilev wrote:
On 01/08/2013 08:33 PM, Doug Lea wrote:
However, the actual ThreadLocalRandom object is padded to avoid
memory contention (which wouldn't be necessary or useful if already
embedded withing Thread).
I'm
On 09/01/2013 11:04, Aleksey Shipilev wrote:
Thanks, David.
On 01/09/2013 02:55 PM, David Holmes wrote:
Not sure where this is now but FYI you needed two CRs for this: one for
hotspot and one for the JDK. They have different target versions (hs25
vs 8) and depending on the path you use to
On 01/09/2013 04:26 PM, Chris Hegarty wrote:
On 09/01/2013 11:04, Aleksey Shipilev wrote:
Thanks, David.
On 01/09/2013 02:55 PM, David Holmes wrote:
Not sure where this is now but FYI you needed two CRs for this: one for
hotspot and one for the JDK. They have different target versions (hs25
On 09/01/2013 12:27, Aleksey Shipilev wrote:
On 01/09/2013 04:26 PM, Chris Hegarty wrote:
On 09/01/2013 11:04, Aleksey Shipilev wrote:
Thanks, David.
On 01/09/2013 02:55 PM, David Holmes wrote:
Not sure where this is now but FYI you needed two CRs for this: one for
hotspot and one for the
On 01/09/2013 03:36 PM, Doug Lea wrote:
On 01/09/13 06:04, Aleksey Shipilev wrote:
I actually have the question about this. What is the usual pattern for
using AtomicLong.VM_SUPPORTS_LONG_CAS? AtomicLong seems to use Unsafe
directly without the checks. AtomicLongFieldUpdater does the checks.
On 01/09/13 07:42, Aleksey Shipilev wrote:
Sorry, this confuses me even more. This [1] seems to be the version
Scavenging through 9-year-old change-logs is probably
not the best path to resolving confusion :-) There were several
stabs (and back then a highly non-transparent process!) at
On 01/09/2013 01:19 PM, Aleksey Shipilev wrote:
Good stuff.
On 01/07/2013 02:46 AM, David Holmes wrote:
http://cr.openjdk.java.net/~dholmes/8005232/webrev/
Sorry for obnoxious first-time reviewer questions:
a) I think the CAS loop in newReflectionData() is misleading in its
reuse of the
Thanks for the explanations, Peter. Initialization loops are nasty.
On 01/09/2013 05:04 PM, Peter Levart wrote:
On 01/09/2013 01:19 PM, Aleksey Shipilev wrote:
c) What's the merit of using Unsafe instead of field updaters
here? (Avoiding the dependency on j.u.c?)
[snip] So if there are any
On 01/09/2013 01:19 PM, Aleksey Shipilev wrote:
e) Should useCaches be final? That will allow aggressive optimizations
for (c).
It could be made final if moved into the ReflectionData class and
initialized in static initializer of that class. Good idea!
I'll check if this is doable.
On 01/09/13 08:04, Aleksey Shipilev wrote:
c) While existing, Java-level AtomicLong.VM_SUPPORT_LONG_CAS is
redundant, and can be eliminated. AtomicLongFieldUpdater can be
rewritten to use Unsafe on all the paths.
There is one little nicety here that does rely on
VM_SUPPORT_LONG_CAS. There
On 01/09/2013 02:47 PM, Peter Levart wrote:
On 01/09/2013 01:19 PM, Aleksey Shipilev wrote:
e) Should useCaches be final? That will allow aggressive optimizations
for (c).
It could be made final if moved into the ReflectionData class and
initialized in static initializer of that class. Good
Hi,
Here is a new webrev in the series that addresses using ServiceLoader in
JAXP for JDK 8.
7169894: JAXP Plugability Layer: using service loader
This changeset addresses modification in the javax.xml.validation
package.
It is a bit more complex than the changes required for the other
Changeset: 86828e84654f
Author:mullan
Date: 2013-01-08 19:00 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86828e84654f
7019834: Eliminate dependency from PolicyFile to
com.sun.security.auth.PrincipalComparator
Summary: Add new java.security.Principal.implies method
Generally the changes looks good, I focused on pack200 and launcher,
the src changes are fine.
Some comments on the tests in test/tools/launcher/profiles, we have a
test/tools/launcher/TestHelper.java which could make these new launcher
tests in the profile directory simpler.
Kumar
On Jan 8,
On 09/01/2013 15:03, Kumar Srinivasan wrote:
Generally the changes looks good, I focused on pack200 and launcher,
the src changes are fine.
Some comments on the tests in test/tools/launcher/profiles, we have a
test/tools/launcher/TestHelper.java which could make these new launcher
tests in the
On 08/01/2013 12:20, Daniel Fuchs wrote:
:
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:
On 09/01/2013 03:58, Mandy Chung wrote:
:
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.
There is a long standing issue (and
On 1/9/2013 7:26 AM, Alan Bateman wrote:
On 09/01/2013 15:03, Kumar Srinivasan wrote:
Generally the changes looks good, I focused on pack200 and launcher,
the src changes are fine.
Some comments on the tests in test/tools/launcher/profiles, we have a
test/tools/launcher/TestHelper.java which
Thanks for the comments Alan!
I have implemented them and refreshed the webrev for the record:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.04/
-- daniel
On 1/9/13 4:43 PM, Alan Bateman wrote:
On 08/01/2013 12:20, Daniel Fuchs wrote:
:
I've clarified the spec. I
Hello again,
I sent this email a week ago and have received no replies. Is there any step I
have missed necessary to contribute to the JDK libraries?
I am very interested in making your lives easier, so please let me know if I am
in the wrong place or are otherwise misguided.
Thanks!
Steven
Please review:
http://cr.openjdk.java.net/~jgish/Bug8005582-WinCommand-test-failures/
http://cr.openjdk.java.net/%7Ejgish/Bug8005582-WinCommand-test-failures/
Summary: this test, when run on Windows, fails intermittently because
of asynchronous windows deletes. The test passes, deletes two
On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish jim.g...@oracle.com wrote:
I'm in the process of adding deletion retry behavior to jtreg, but in the
meantime we think it makes sense to provide a more stable test environment
by simply getting rid of the redundant deletes by the test itself. There
The Threeten project [1] is planned to be integrated into OpenJDK with
the M6 milestone.
The javadoc [2] (aka JSR 310 specification) for the new Java Time packages
is available for review. Comments can be sent to the threeten-dev email
list [3] or
entered in the issue tracker [4].
When
On 01/09/2013 02:33 PM, Martin Buchholz wrote:
On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish jim.g...@oracle.com
mailto:jim.g...@oracle.com wrote:
I'm in the process of adding deletion retry behavior to jtreg, but
in the meantime we think it makes sense to provide a more stable
Please review at your convenience.
Issue
https://jbs.oracle.com/bugs/browse/JDK-7103957
The problem and suggested fix provided in the issue description are accurate:
the array is one element too large.
Diff
--- a/src/share/classes/java/lang/Integer.java Tue Nov 13 20:02:39 2012 -0800
+++
On 09/01/2013 17:26, Daniel Fuchs wrote:
Thanks for the comments Alan!
I have implemented them and refreshed the webrev for the record:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.04/
-- daniel
You've addressed my comments so thumbs up from me on this chapter.
http://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
Looks good for me. I will sponsor these changes after we get a review
from JDK side.
Thanks,
Vladimir
On 12/20/12 11:03 AM, Aleksey Shipilev wrote:
Hi,
Sorry for cross-list posting, but this change affects both HS and JDK.
This simple change is missing from recently committed CR 7023898.
On 1/9/2013 9:26 AM, Daniel Fuchs wrote:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.04/
Daniel - thanks for updating the spec for the newFactory(String,
ClassLoader) method.
In XMLEventFactory.java (and same comment apply to XMLInputFactory and
Looks fine; approved.
Cheers,
-Joe
On 1/9/2013 11:58 AM, Brian Burkhalter wrote:
Please review at your convenience.
Issue
https://jbs.oracle.com/bugs/browse/JDK-7103957
The problem and suggested fix provided in the issue description are accurate:
the array is one element too large.
Diff
On 01/09/2013 11:05 PM, Ioi Lam wrote:
http://cr.openjdk.java.net/~coleenp/8005466_zip_util_001/
http://cr.openjdk.java.net/%7Ecoleenp/8005466_zip_util_001/
(I'm not the sponsor).
Nice patch, I can see the reasoning behind the issue and the fix.
-Aleksey.
I think Sherman agreed to sponsor this change. If not, I can help get it on.
-Chris
On 9 Jan 2013, at 20:52, Aleksey Shipilev aleksey.shipi...@oracle.com wrote:
On 01/09/2013 11:05 PM, Ioi Lam wrote:
http://cr.openjdk.java.net/~coleenp/8005466_zip_util_001/
I'm running it through jprt now. I will push this in for Ioi, if everything
goes well.
On 01/09/2013 01:03 PM, Chris Hegarty wrote:
I think Sherman agreed to sponsor this change. If not, I can help get it on.
-Chris
On 9 Jan 2013, at 20:52, Aleksey Shipilevaleksey.shipi...@oracle.com wrote:
Hi Mandy,
Please find clarifications in line:
On 1/9/13 9:30 PM, Mandy Chung wrote:
On 1/9/2013 9:26 AM, Daniel Fuchs wrote:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.04/
Daniel - thanks for updating the spec for the newFactory(String,
ClassLoader) method.
On 20 Dec 2012, at 19:21, Vladimir Kozlov vladimir.koz...@oracle.com wrote:
Looks good for me. I will sponsor these changes after we get a review from
JDK side.
Have I missed something, or are these changes not already in?
-Chris
Thanks,
Vladimir
On 12/20/12 11:03 AM, Aleksey
On Wed, Jan 9, 2013 at 11:05 AM, Ioi Lam ioi@oracle.com wrote:
Repository used:
I
usedhttp://hg.openjdk.java.**net/hsx/hotspot-rt/http://hg.openjdk.java.net/hsx/hotspot-rt/.
Not sure if this is the
right repo to use.
This is not a hotspot change, so this doesn't go into a hotspot
Hello,
Please review the core reflection API implementation of parameter
reflection. This is the final component of method parameter reflection.
This was posted for review before, then delayed until the check-in for
JDK-8004728 (hotspot support for parameter reflection), which occurred
Is there someone willing to sponsor this fix?
Thanks,
Brian
On Jan 9, 2013, at 12:48 PM, Joe Darcy wrote:
Looks fine; approved.
Cheers,
-Joe
On 1/9/2013 11:58 AM, Brian Burkhalter wrote:
Please review at your convenience.
Issue
https://jbs.oracle.com/bugs/browse/JDK-7103957
(resending to all lists)
It is in promoted build jdk8b71 already:
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/8cf5b18488d1
Vladimir
On 1/9/13 1:17 PM, Chris Hegarty wrote:
On 20 Dec 2012, at 19:21, Vladimir Kozlov vladimir.koz...@oracle.com wrote:
Looks good for me. I will sponsor these
Please review the following:
Webrev:
http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/
http://cr.openjdk.java.net/%7Ejgish/Bug4247235-Add-Blanket-Null-Stmt/
Here's a specdiff:
http://cr.openjdk.java.net/~jgish/Bug4247235-string-specdiff/
AbstractStringBuilder probably needs the Unless otherwise noted, blanket
statement as well (Same as StringBuffer/StringBuilder)
You might want to move the Objects.requireNonNull(dst); in String.getBytes() to
after the existing checks so as not to unnecessarily change the exception
thrown for
On 1/9/2013 1:13 PM, Daniel Fuchs wrote:
Hi Mandy,
Please find clarifications in line:
On 1/9/13 9:30 PM, Mandy Chung wrote:
Since there is a behavioral change, the following statements are
not true
any more and I think they can be removed.
166* No changes in behavior are defined
Another little simplification:
179 boolean overflow = sr dr;
180 sr = overflow ? dr : sr;
or in your existing logic:
178 int len = sl - sp;
179 boolean overflow = len (dl - dp);
180 len = overflow ? dl - dp : len;
(len is
I can sponsor this fix.
Mandy
On 1/9/2013 2:19 PM, Brian Burkhalter wrote:
Is there someone willing to sponsor this fix?
Thanks,
Brian
On Jan 9, 2013, at 12:48 PM, Joe Darcy wrote:
Looks fine; approved.
Cheers,
-Joe
On 1/9/2013 11:58 AM, Brian Burkhalter wrote:
Please review at your
On 1/9/13 11:33 AM, Martin Buchholz wrote:
On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish jim.g...@oracle.com wrote:
I'm in the process of adding deletion retry behavior to jtreg, but in the
meantime we think it makes sense to provide a more stable test environment
by simply getting rid of the
Changeset: 4c8b37f159f9
Author:mchung
Date: 2013-01-09 16:58 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c8b37f159f9
7103957: NegativeArraySizeException while initializing class IntegerCache
Reviewed-by: darcy, mchung
Contributed-by: brian.burkhal...@oracle.com
!
Hey,
This is a cute bug (maybe a bug in java.io or jtreg or jtharness; not sure).
$ perl -e 'utime 0, 0, java/lang/String' ls -ld java/lang/String
~/jct-tools/jtreg-4.1-b5/linux/bin/jtreg java/lang/String/IsEmpty.java
drwxr-x--- 2 martinrb eng 4096 Dec 31 1969 java/lang/String
Error: Bad
On further consideration...
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)
- the accumulator function is always called for initial allocations of
On 1/6/2013 2:46 PM, David Holmes wrote:
http://cr.openjdk.java.net/~dholmes/8005232/webrev/
This looks good to me. David - besides the footprint performance data,
do you observe any performance difference in your performance testing
(I think refworkload is what you ran)?
On 01/09/2013 01:19
Well, if this is the behavior you can expect from Windows, carry on!
But how can anyone get reliable behavior if a file delete can fail
capriciously in two dimensions - it might be in use , or it might be an
already deleted ghost?
I'm not claiming to be a reviewer for this change.
On Wed, Jan
On 9/01/2013 9:04 PM, Aleksey Shipilev wrote:
Thanks, David.
On 01/09/2013 02:55 PM, David Holmes wrote:
Not sure where this is now but FYI you needed two CRs for this: one for
hotspot and one for the JDK. They have different target versions (hs25
vs 8) and depending on the path you use to
Changeset: 7612fe48be90
Author:darcy
Date: 2013-01-09 20:02 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7612fe48be90
8004730: Add language model support for parameter reflection
Reviewed-by: abuckley
! src/share/classes/javax/lang/model/element/Element.java
!
Changeset: 4176e6cc499e
Author:darcy
Date: 2013-01-09 20:20 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4176e6cc499e
8005713: Simplify library support for repeating annotations in
java.lang.annotation
Reviewed-by: abuckley
+
On 1/9/13 5:26 PM, Martin Buchholz wrote:
Well, if this is the behavior you can expect from Windows, carry on!
But how can anyone get reliable behavior if a file delete can fail capriciously
in two dimensions - it might be in use , or it might be an already deleted
ghost?
In other words, how
On 1/9/13 10:49 AM, Jim Gish wrote:
Please review:
http://cr.openjdk.java.net/~jgish/Bug8005582-WinCommand-test-failures/
http://cr.openjdk.java.net/%7Ejgish/Bug8005582-WinCommand-test-failures/
Summary: this test, when run on Windows, fails intermittently because of
asynchronous windows
Hi Lance,
Is there any update for this issue. If you have anything I can do,
please let me know.
Thanks a lot!
On 11/24/2012 12:45 AM, Lance Andersen - Oracle wrote:
It is on my list. to update the javadocs I need a ccc which I have
not done yet and is needed as part of this change
On Nov
Hi Eric,
A few quick comments. In Executable,
228 /**
229 * Returns the number of formal parameters for the executable
230 * represented by this object.
231 *
232 * @return The number of formal parameters for the executable this
233 * object represents
234
Hi Aleksey,
Thanks for the feedback. Let me prefix this by saying that time is of
the essence here so unless there is a major issue things will go in as
is, with follow ups for after M6 if needed. We can't miss M6 but we can
tweak the initial changes after M6.
On 9/01/2013 10:19 PM, Aleksey
Hi Mandy,
Thanks for the review.
On 10/01/2013 11:25 AM, Mandy Chung wrote:
On 1/6/2013 2:46 PM, David Holmes wrote:
http://cr.openjdk.java.net/~dholmes/8005232/webrev/
This looks good to me. David - besides the footprint performance data,
do you observe any performance difference in your
71 matches
Mail list logo
