Changeset: 92164a5742db
Author:lagergren
Date: 2013-05-20 16:38 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/92164a5742db
8006069: Range analysis first iteration, runtime specializations
Reviewed-by: jlaskey, sundar
! src/jdk/nashorn/internal/codegen/CompilationPhase.j
On 20/05/2013 16:07, Amy Lu wrote:
More ProblemList updates to remove three tests, the related issues
have been fixed.
Please review:
https://dl.dropboxusercontent.com/u/5812451/yl153753/8014892/webrev/index.html
Thanks,
Good to catch cases where we neglected to remove the tests from the
On 18/05/2013 08:57, Chris Hegarty wrote:
Thread getName and setName are not thread-safe. The "expected" usage
is to set a name before starting the thread and only read it thereafter.
It is desirable to support the setting of thread name dynamically,
mainly for monitoring/management/debugging.
On 5/21/13 3:53 PM, Alan Bateman wrote:
On 20/05/2013 16:07, Amy Lu wrote:
More ProblemList updates to remove three tests, the related issues
have been fixed.
Please review:
https://dl.dropboxusercontent.com/u/5812451/yl153753/8014892/webrev/index.html
Thanks,
Good to catch cases where w
On 5/21/2013 1:42 AM, Kurchi Hazra wrote:
Hi,
Please review this change to fix 718655. The bug complaints about
continuous BackingStoreExceptions
printed on the console, the user is just seeing logged warnings from
BackingStoreExceptions raised in periodic attempts to sync
preferences. Pr
On 21/05/2013 03:12, David Holmes wrote:
So I propose to push ahead with this fix in my offered form.
I still need an official Review to do so, or else objections against
the proposal.
I think what you have is fine, the other candidates were fine too. This
issue is another reminder that we nee
Kurchi,
The windows implementation also emits warning messages that should be
fixed up too since we don't want to emit anything to interfere the
application logging. The default logging configuration (default level
is INFO) should apply to the application logging and the runtime like
this ca
Changeset: 67cbd6d756f4
Author:jfranck
Date: 2013-05-21 12:00 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/67cbd6d756f4
8013180: Qualified type reference with annotations in throws list crashes
compiler
Reviewed-by: jjg
+ test/tools/javac/annotations/typeAnnotations
Changeset: 824932ecdbc8
Author:vromero
Date: 2013-05-21 11:41 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/824932ecdbc8
7177168: Redundant array copy in UnsharedNameTable
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java
Jason,
Thank you for looking into this patch.
Actually, the readObject calls the super.initCause, because there is no
initCause in XPathException.
About 'super.getCause() == null' check: yes it can be done in such way.
In current version I caught the IllegalStateException to correctly
process t
Hi Petr,
The fix looks good to me. We still need a review from someone who
maintains the Launcher code. Kumar?
Also, you could use the @autoreleasepool directive to simplify it a bit,
although I'm fine with the explicit syntax, too.
One comment regarding your remark:
c. We would have lost
Changeset: 3d9750039fff
Author:vromero
Date: 2013-05-21 12:17 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d9750039fff
7060779: test/tools/javac/diags/Example.java leaves directories in tempdir
Reviewed-by: mcimadamore
! test/tools/javac/diags/Example.java
Hi Joe,
I applied the patch and built a jdk, looks good to me.
(Not a Reviewer kind of reviewer tough.)
cheers
/Joel
On 20 maj 2013, at 23:10, Joe Darcy wrote:
> Hello,
>
> Please review the patch below which implements
>
>8014836: Have GenericDeclaration extend AnnotatedElement
>
> Al
Hi,
It is time to add the proper Javadoc to @Contended:
http://cr.openjdk.java.net/~shade/8014966/webrev.01/
Testing:
- built jdk8-tl on Linux x86_64/release without a hitch.
Please review and sponsor!
Thanks,
-Aleksey.
Changeset: 08daea43a7f8
Author:vromero
Date: 2013-05-21 14:33 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/08daea43a7f8
7164114: Two jtreg tests are not run due to no file extension on the test files
Reviewed-by: mcimadamore
- test/tools/javac/HiddenAbstractMethod/Te
On 5/21/13 1:35 AM, Mandy Chung wrote:
Kurchi,
The windows implementation also emits warning messages that should be
fixed up too since we don't want to emit anything to interfere the
application logging. The default logging configuration (default level
is INFO) should apply to the applicati
On 05/21/2013 06:07 AM, Mike Duigou wrote:
Looks good.
Since the char array is never modified it could use the String(char[], boolean)
constructor. This has advantages for cases such as logging which may read the
thread name very many times.
Thanks Mike, this would be a nice improvement.
Fi
Any chance that it would be possible to stop the periodic attempts to sync
preferences?
The log spamming is a symptom, not the cause.
Could the prefs code be enhanced to better determine if writing is possible
before attempting and failing?
Mike
On May 21 2013, at 01:21 , Mandy Chung wrote:
Aleksej,
> Actually, the readObject calls the super.initCause, because there is no
> initCause in XPathException.
I would think that subclasses of XPE will see calls to this.initCause from
readObject. That wouldn't have happened prior to this change.
> About 'super.getCause() == null' check: yes
On 5/21/13 9:40 AM, Mike Duigou wrote:
Any chance that it would be possible to stop the periodic attempts to sync
preferences?
- I did think of that too - but the syncing may fail(temporarily) if the
prefs object could not retrieve the lock to the
associated prefs file. We could stop syncing
I don't have any way to verify this change but comparing it to the other
jvm.cfg files it appears to be correct.
Mike
On May 20 2013, at 22:02 , David Holmes wrote:
> Anybody? :(
>
> David
>
> On 20/05/2013 12:06 PM, David Holmes wrote:
>> The contents of the ARM jvm.cfg were put in place fo
On 5/21/13 9:53 AM, Kurchi Subhra Hazra wrote:
On 5/21/13 9:40 AM, Mike Duigou wrote:
Any chance that it would be possible to stop the periodic attempts to
sync preferences?
- I did think of that too - but the syncing may fail(temporarily) if
the prefs object could not retrieve the lock to th
On May 21 2013, at 09:53 , Kurchi Subhra Hazra wrote:
> On 5/21/13 9:40 AM, Mike Duigou wrote:
>> Any chance that it would be possible to stop the periodic attempts to sync
>> preferences?
>
> - I did think of that too - but the syncing may fail(temporarily) if the
> prefs object could not ret
On May 21 2013, at 10:04 , Kurchi Subhra Hazra wrote:
> On 5/21/13 9:53 AM, Kurchi Subhra Hazra wrote:
>> On 5/21/13 9:40 AM, Mike Duigou wrote:
>>> Any chance that it would be possible to stop the periodic attempts to sync
>>> preferences?
>>
>> - I did think of that too - but the syncing may
Right - I think I can disable syncing attempts for a file once we get an
EACCESS error code . Locked files
should return EAGAIN. I'll have to check on how this works on
Solaris/Linux/Mac and will follow up.
Thanks for digging up the history.
- Kurchi
On 5/21/2013 10:28 AM, Mike Duigou wrote:
Added macosx-port-dev
On May 21, 2013, at 10:57 AM, David Holmes wrote:
> Adding core-libs as this is actually a launcher change.
>
> David
>
> On 21/05/2013 4:36 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>>
>> Please review the fix for the issue:
>> http://bugs.sun.com/view_bug.do?bug_id=80
http://cr.openjdk.java.net/~drchase/7088419/webrev.03/
Newer, slimmer webrev. No fork/join, the related code is removed (except the
native init routine still returns a boolean, which is currently ignored,
indicating if
it supports the faster crc32).
What remains is:
1) no-JNI fast-path for sh
Hello all;
A lot more people have been playing with using concurrency lately with JTReg
and most have found that tests will frequently fail or error out because of OOM
errors. The problem is that the jdk/test/Makefile currently doesn't specify a
size for the vm instances used for running tests.
Ping!
I need a final review on this issue.
Thanks,
Mike
On May 16 2013, at 14:02 , Mike Duigou wrote:
>
> On May 15 2013, at 19:09 , Joseph Darcy wrote:
>
>> Hi Mike,
>>
>> Looks fine. Are you satisfied with the test coverage provided by the
>> existing regression tests?
>
> I hadn't actu
Looks fine.
-Joe
On 5/21/2013 3:42 PM, Mike Duigou wrote:
Hello all;
A lot more people have been playing with using concurrency lately with JTReg and most
have found that tests will frequently fail or error out because of OOM errors. The
problem is that the jdk/test/Makefile currently doesn'
Hello Mike,
The TestNG data provider framework is unfamiliar to me, so my first
reaction is that it is overkill for this problem as opposed to a one-off
approach, but that may be driven my lack of experience with it.
However, in the test code
153 private static final long[] SOME_PRIMES
Still okay with me.
Thanks,
David
On 22/05/2013 1:58 AM, Chris Hegarty wrote:
On 05/21/2013 06:07 AM, Mike Duigou wrote:
Looks good.
Since the char array is never modified it could use the String(char[],
boolean) constructor. This has advantages for cases such as logging
which may read the th
Hello,
Yes; Kumar should be one of the reviewers here.
Thanks,
-Joe
On 05/21/2013 04:18 AM, Anthony Petrov wrote:
Hi Petr,
The fix looks good to me. We still need a review from someone who
maintains the Launcher code. Kumar?
Also, you could use the @autoreleasepool directive to simplify i
33 matches
Mail list logo
