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
srikalyan.chandrashe...@oracle.com
mailto:srikalyan.chandrashe...@oracle.com wrote:
Suggested Fix
this if you don't have an account yet.)
Thanks,
David
On 19/11/2013 4:12 PM, srikalyan chandrashekar wrote:
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
for the suggestion) instead of
decreasing the timeout as done earlier because the increasing iterations
ensures the threads are busy for long time curtailing the need to touch
the timeout.
Thanks,
David
--
Thanks
kalyan
Ph: (408)-585-8040
On Wed, Nov 20, 2013 at 11:52 AM, srikalyan
Hi David/Martin a gentle reminder for review.
--
Thanks
kalyan
Ph: (408)-585-8040
On 12/2/13, 11:21 AM, srikalyan wrote:
Hi David, Thanks for the review, the new webrev is hosted at
http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/
. Please see inline text.
On 11/20/13
Hi all, a gentle reminder for review.
--
Thanks
kalyan
Ph: (408)-585-8040
On 12/2/13, 6:39 PM, srikalyan chandrashekar wrote:
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
just fail if it does.
David
On 10/12/2013 6:15 AM, srikalyan wrote:
Hi David/Martin a gentle reminder for review.
--
Thanks
kalyan
Ph: (408)-585-8040
On 12/2/13, 11:21 AM, srikalyan wrote:
Hi David, Thanks for the review, the new webrev is hosted at
http://cr.openjdk.java.net/~cl
Hi Mandy, yes I ran with JTreg to simulate the failure, i will try the
UEH patch to see if it sheds some light and get back to you. Thanks for
the direction :)
--
Thanks
kalyan
Ph: (408)-585-8040
On 12/19/13, 8:33 PM, Mandy Chung wrote:
Hi Srikalyan,
Maybe you can get add an uncaught
On 1/11/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
Hi David
On 1/15/14, 9: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
Hi Peter/David, catching up after long weekend. Why would there be an
OOME in object heap due to class loading in perm gen space ? Please
correct if i am missing something here. Meanwhile i will give the
version of Reference Handler you both agreed on a try.
--
Thanks
kalyan
Ph:
-data would be in native
memory(not heap).
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 2:31 PM, Peter Levart wrote:
On 01/21/2014 07:17 PM, srikalyan wrote:
Hi Peter/David, catching up after long weekend. Why would there be an
OOME in object heap due to class loading in perm gen space
Hi Peter/David, we have 2000 runs without a single failure.
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/23/14, 12:10 PM, srikalyan wrote:
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because
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
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-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
drop hotspot from any replies.
On 20/12/2013 6:26 AM, srikalyan wrote:
Hi all, I have been working on the bug JDK-8022321
https://bugs.openjdk.java.net/browse/JDK-8022321 , this is a sporadic
failure and the webrev is available here
http://cr.openjdk.java.net/~srikchan/Regression/JDK
Hi David/Martin, could any one of you sponsor this change for me?
---
Thanks
kalyan
On 12/20/2013 10:28 PM, David Holmes wrote:
On 21/12/2013 4:19 AM, srikalyan wrote:
Hi David, i retained only the changes to ITERS, ProbleMList.txt and
upstream changes by Doug Lea(as pointed by Martin), could
)
at
com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
at java.lang.Thread.run(Thread.java:744)
Meanwhile i am trying looking around to actually print something useful
without allocating any new memory.
---
Thanks
kalyan
On 12/20/2013 01:00 PM, srikalyan
, 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
/%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
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
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
that the additional guard should be allowed,
however i might still be ignorant of vital implications.
- Apart from the above changes, Peter's suggestion to create and call a
private runImpl() from run() in ReferenceHandler makes sense to me.
---
Thanks
kalyan
On 01/13/2014 03:57 PM, srikalyan wrote:
On 1/11
Hi David, the disassembled code is also attached to the bug. Per my
analysis the exception was thrown when Reference Handler was on line 143
as put in the earlier email.
--
Thanks
kalyan
On 1/16/14 6:16 PM, David Holmes wrote:
On 17/01/2014 4:48 AM, srikalyan wrote:
Hi David
On 1/15/14, 9
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
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
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
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
29 matches
Mail list logo
