On 11/04/2013 07:52 AM, Peter Levart wrote:
Also VM.awaitBooted seems inherently risky as a general method as
you would have to make sure that it is never called by the main VM
initialization thread. Perhaps handle this in
sun.misc.SharedSecrets.getJavaLangAccess so it is less 'general'?
Tha
On 4/11/2013 4:40 PM, Martin Buchholz wrote:
David and I might prefer a fix using AtomicInteger, but I don't think
there's anything incorrect with your fix - approved. Especially if you
have seen the flakiness has gone away. (I've never seen this test fail.)
+1
David
On Sun, Nov 3, 2013 a
On 11/04/2013 05:45 AM, Mandy Chung wrote:
On 11/3/2013 5:32 PM, David Holmes wrote:
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/w
Hi Mandy,
I'll wait for the updated webrev.
FYI I wasn't suggesting any VM changes regarding GetMethodID. I assumed,
incorrectly, that once you had the method ID you could query to see if
it was private. That said if you called GetMethodID on Object.class and
then did the CallVoidMethod(env,
Changeset: ae5f2130c3b9
Author:sundar
Date: 2013-11-01 19:54 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ae5f2130c3b9
8027700: function redeclaration checks missing for declaration binding
instantiation
Reviewed-by: jlaskey, lagergren
! src/jdk/nashorn/internal/codeg
On 11/3/2013 5:32 PM, David Holmes wrote:
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: I
On 11/2/2013 3:41 AM, Peter Levart wrote:
On 11/01/2013 10:11 PM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In Finali
Thank you Martin
I updated the code as below
http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.02/
Thank you
On 11/04/2013 11:38 AM, Martin Buchholz wrote:
Tristan, I think your change it correct.
There are some stylistic improvements I would make:
- make lock final
- make lessThanC
On 4/11/2013 1:42 PM, Martin Buchholz wrote:
On Sun, Nov 3, 2013 at 5:09 PM, David Holmes wrote:
Locking access to a CountDownLatch just seems inherently wrong. I get that
it is the atomicity of the two calls that we want, but this still seems
unpleasant. I've looked at Martin's suggested fix
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In Finalizer.java, at line 97 you look up the
Hi Tristan,
On 4/11/2013 10:49 AM, Tristan Yan wrote:
Thank you Martin
I had code change. I took the similar way as you do here.
Please review the code change for JDK-8025198.
Description:
Race condition exists in the test ThrowingTasks.java. We should sync
CountDownLatch.countDown and CountDow
Thank you Martin
I had code change. I took the similar way as you do here.
Please review the code change for JDK-8025198.
Description:
Race condition exists in the test ThrowingTasks.java. We should sync
CountDownLatch.countDown and CountDownLatch.getCount.
http://cr.openjdk.java.net/~ewang/tr
Changeset: adcc01f5bc93
Author:jrose
Date: 2013-11-02 20:08 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/adcc01f5bc93
8024635: Caching MethodType's descriptor string improves lambda linkage
performance
Summary: Better interpreted and compiled performance of operations in
13 matches
Mail list logo
