On 1/26/14 11:07 AM, Peter Levart wrote:
On 01/25/2014 05:35 AM, srikalyan chandrashekar wrote:
Hi Peter, if you are a committer would you like to take this further
(OR) perhaps david could sponsor this change.
Hi,
Here's new webrev that takes into account Kaylan's and David's review
Hi Peter, if you are a committer would you like to take this further
(OR) perhaps david could sponsor this change.
--
Thanks
kalyan
On 1/24/14 4:05 PM, Peter Levart wrote:
On 01/24/2014 02:53 AM, srikalyan chandrashekar wrote:
Hi David, yes thats right, only benefit i see is we can avoid
Hi David, yes thats right, only benefit i see is we can avoid assignment
to 'r' if pending is null.
--
Thanks
kalyan
On 1/23/14 4:33 PM, David Holmes wrote:
On 24/01/2014 6:10 AM, srikalyan wrote:
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
:04 PM, David Holmes wrote:
On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote:
Hi Peter/David, we could finally get a trace of exception with
fastdebug
build and ReferenceHandler modified (with runImpl() added and called
from run()). The logs, disassembled code is available in JIRA
https
On 1/16/14 8:38 PM, David Holmes wrote:
On 17/01/2014 1:31 PM, srikalyan chandrashekar wrote:
Hi David, the disassembled code is also attached to the bug. Per my
Sorry missed that.
analysis the exception was thrown when Reference Handler was on line 143
as put in the earlier email
/14, 6:15 AM, Peter Levart wrote:
On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote:
Hi Peter the version you provided ran indefinitely(i put a 10 minute
timeout) and the program got interrupted(no error),
Did you run it with or without fastedbug -XX:+TraceExceptions ? If
with, it might
Hi Peter the version you provided ran indefinitely(i put a 10 minute
timeout) and the program got interrupted(no error), even if there were
to be an error you cannot print the string of thread to console(these
have been attempted earlier).
- The test's running on interpreter mode, what i am
wrote:
On 8/01/2014 4:19 PM, David Holmes wrote:
On 8/01/2014 7:33 AM, srikalyan chandrashekar wrote:
Hi David, TraceExceptions with fastdebug build produced some nice
trace
http://cr.openjdk.java.net/%7Esrikchan/OOME_exception_trace.log
. The
native method wait(long) is where the OOME if being
/%7Esrikchan/OOME_exception_trace.log .
---
Thanks
kalyan
On 01/07/2014 12:42 AM, Peter Levart wrote:
On 01/07/2014 03:15 AM, srikalyan chandrashekar wrote:
Sure David will give that a try, we have so far attempted to
1. Print state data(as per the test creator peter.levart's inputs),
Hi Kalyan,
Have
-
Would be helpful if David/some one else in the team could explain the
latent aspects/probable cause.
---
Thanks
kalyan
On 01/06/2014 04:40 PM, David Holmes wrote:
Back from vacation ...
On 20/12/2013 4:49 PM, David Holmes wrote:
On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote:
Hi David
, David Holmes wrote:
On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote:
Hi David Thanks for your comments, the unguarded part(clean and
enqueue)
in the Reference Handler thread does not seem to create any new
objects,
so it is the application(the test in this case) which is adding objects
to heap
and down, but the test
just keeps
on passing for me. Hints appreciated.
Bump up the timeout to 500ms and you will see a failure (i can
see it
consistently on my machine Linux 64bit,8GBRAM,dual cores, with
JDK 1.8
latest any promoted build).
On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar
.);
}
+ referenceHandlerThread.setUncaughtExceptionHandler(new UEH());
+
ReferenceQueueObject refQueue = new ReferenceQueue();
Object referent = new Object();
WeakReferenceObject weakRef = new
WeakReference(referent, refQueue);
On 12/19/2013 6:57 PM, srikalyan chandrashekar wrote:
Hi David Thanks
Hi David Thanks for your comments, the unguarded part(clean and enqueue)
in the Reference Handler thread does not seem to create any new objects,
so it is the application(the test in this case) which is adding objects
to heap and causing the Reference Handler to die with OOME. I am still
Hi all, I am working on bug JDK-6963118
https://bugs.openjdk.java.net/browse/JDK-6963118 .
Root Cause:
- Sensitive timing dependency between events in Main and Sleeper threads
are causes for test failure.
Suggested Fix:
1) Main thread should wait for more than 1sec(made it 3sec) and check
maintainers haven't been able to reproduce any failures in
this test. Do you have any hints that might help us?
On Mon, Nov 18, 2013 at 10:12 PM, srikalyan chandrashekar
srikalyan.chandrashe...@oracle.com
mailto:srikalyan.chandrashe...@oracle.com wrote:
Hi all, I am working on bug JDK-6772009
Hi all, I am working on bug JDK-6772009
https://bugs.openjdk.java.net/browse/JDK-6772009 .
Root Cause:
The timeout value gives too much grace period on faster machines on
which the TO BE INTERRUPTED threads complete faster before being
interrupted at right time.
Suggested Fix:
a) Decrease
17 matches
Mail list logo
