I've just sent out an RFR for
8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java
The proposed fix incorporates the change suggested by Per and
discussed in this thread of moving the pending reference list
management entirely into the VM.
Hi Kim,
On 03/23/2016 09:40 PM, Kim Barrett wrote:
I don't think there's any throughput penalty for a long timeout. The
proper response to waitForCleanups returning false (assuming the epoch
was obtained early and passed as an argument) is OOME. I really doubt
the latency for reporting OOME
> On Mar 23, 2016, at 4:42 PM, Peter Levart wrote:
>
> Hi Kim,
>
> Thinking more about your approach. Basically your idea is to detect that
> there are no more unprocessed but pending or enqueued Cleanables by timing
> out on waiting for next Cleanable to be processed.
On 03/23/2016 09:40 PM, Kim Barrett wrote:
On Mar 23, 2016, at 3:33 PM, Peter Levart wrote:
Hi Kim,
On 03/23/2016 07:55 PM, Kim Barrett wrote:
On Mar 23, 2016, at 10:02 AM, Peter Levart
wrote:
...so I checked what it would be needed if
Hi Kim,
Thinking more about your approach. Basically your idea is to detect that
there are no more unprocessed but pending or enqueued Cleanables by
timing out on waiting for next Cleanable to be processed. In that case
the timeout should be reset when each Cleanable is detected to be
> On Mar 23, 2016, at 3:33 PM, Peter Levart wrote:
>
> Hi Kim,
>
> On 03/23/2016 07:55 PM, Kim Barrett wrote:
>>> On Mar 23, 2016, at 10:02 AM, Peter Levart
>>> wrote:
>>> ...so I checked what it would be needed if there was such
>>>
Hi Kim,
On 03/23/2016 07:55 PM, Kim Barrett wrote:
On Mar 23, 2016, at 10:02 AM, Peter Levart wrote:
...so I checked what it would be needed if there was such
getPendingReferences() native method. It turns out that a single native method
would not be enough to support
> On Mar 23, 2016, at 10:02 AM, Peter Levart wrote:
> ...so I checked what it would be needed if there was such
> getPendingReferences() native method. It turns out that a single native
> method would not be enough to support the precise direct ByteBuffer
> allocation.
Hi Peter,
On 2016-03-23 15:02, Peter Levart wrote:
Hi Per, Kim,
On 03/22/2016 10:24 AM, Per Liden wrote:
So, I imagine the ReferenceHandler could do something like this:
while (true) {
// getPendingReferences() is a downcall to the VM which
// blocks until the pending list becomes
Hi Per, Kim,
On 03/22/2016 10:24 AM, Per Liden wrote:
So, I imagine the ReferenceHandler could do something like this:
while (true) {
// getPendingReferences() is a downcall to the VM which
// blocks until the pending list becomes non-empty and
// returns the whole list,
Hi,
On 2016-03-23 08:13, Peter Levart wrote:
On 03/22/2016 10:28 PM, Kim Barrett wrote:
On Mar 22, 2016, at 5:24 AM, Per Liden wrote:
One thing I like about this approach is that it's only the
ReferenceHandler thread that pops of elements from the pending list
and
On 03/22/2016 10:28 PM, Kim Barrett wrote:
On Mar 22, 2016, at 5:24 AM, Per Liden wrote:
One thing I like about this approach is that it's only the ReferenceHandler
thread that pops of elements from the pending list and enqueues them. That
simplifies things a lot.
I
> On Mar 22, 2016, at 5:24 AM, Per Liden wrote:
> One thing I like about this approach is that it's only the ReferenceHandler
> thread that pops of elements from the pending list and enqueues them. That
> simplifies things a lot.
I like that too. And hopefully we really
Hi Peter,
On 2016-03-21 16:30, Peter Levart wrote:
Hi Per,
May I point you to my proposed change in Reference(Handler) for JDK 9,
being discussed in the thread about JDK-8149925. It will hopefully
remove the special-casing of sun.misc.Cleaner, change the way how
pending references are being
On 2016-03-21 18:32, Kim Barrett wrote:
On Mar 21, 2016, at 8:20 AM, Per Liden wrote:
Hi Peter & David,
(Resurrecting an old thread here...)
On 2014-01-22 03:19, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing up
Hi Peter,
On 2016-03-21 16:13, Peter Levart wrote:
Hi Per, David,
As things stand, there is a very good chance that sun.misc.Cleaner will
go away in JDK9, so all this speculation about the source of OOME(s) can
be put to rest. But for JDK 8u, I agree that this should be sorted out.
My feeling
On 22/03/2016 3:32 AM, Kim Barrett wrote:
On Mar 21, 2016, at 8:20 AM, Per Liden wrote:
Hi Peter & David,
(Resurrecting an old thread here...)
On 2014-01-22 03:19, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing
On 21/03/2016 11:41 PM, Per Liden wrote:
Hi David,
On 2016-03-21 13:49, David Holmes wrote:
Hi Per,
On 21/03/2016 10:20 PM, Per Liden wrote:
Hi Peter & David,
(Resurrecting an old thread here...)
On 2014-01-22 03:19, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart
> On Mar 21, 2016, at 8:20 AM, Per Liden wrote:
>
> Hi Peter & David,
>
> (Resurrecting an old thread here...)
>
> On 2014-01-22 03:19, David Holmes wrote:
>> Hi Peter,
>>
>> On 22/01/2014 12:00 AM, Peter Levart wrote:
>>> Hi, David, Kalyan,
>>>
>>> Summing up the
On 03/21/2016 04:13 PM, Peter Levart wrote:
Hi Per, David,
As things stand, there is a very good chance that sun.misc.Cleaner
will go away in JDK9, so all this speculation about the source of
OOME(s) can be put to rest. But for JDK 8u, I agree that this should
be sorted out.
My feeling
Hi Per,
May I point you to my proposed change in Reference(Handler) for JDK 9,
being discussed in the thread about JDK-8149925. It will hopefully
remove the special-casing of sun.misc.Cleaner, change the way how
pending references are being enqueued by ReferenceHandler thread and how
other
Hi Per, David,
As things stand, there is a very good chance that sun.misc.Cleaner will
go away in JDK9, so all this speculation about the source of OOME(s) can
be put to rest. But for JDK 8u, I agree that this should be sorted out.
My feeling is that (instanceof Cleaner) can not result in
Hi David,
On 2016-03-21 13:49, David Holmes wrote:
Hi Per,
On 21/03/2016 10:20 PM, Per Liden wrote:
Hi Peter & David,
(Resurrecting an old thread here...)
On 2014-01-22 03:19, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing up the
Hi Per,
On 21/03/2016 10:20 PM, Per Liden wrote:
Hi Peter & David,
(Resurrecting an old thread here...)
On 2014-01-22 03:19, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing up the discussion, I propose the following patch for
Hi Peter & David,
(Resurrecting an old thread here...)
On 2014-01-22 03:19, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing up the discussion, I propose the following patch for
ReferenceHandler:
On 29/01/2014 19:10, Mandy Chung wrote:
On 1/29/2014 5:09 AM, Peter Levart wrote:
Since I don't know what should be the correct behaviour of javac, I
can leave the Reference.java changes as proposed since it compiles in
both cases. Or should I revert the change to declaration of local
On 01/30/2014 03:46 PM, Alan Bateman wrote:
On 29/01/2014 19:10, Mandy Chung wrote:
On 1/29/2014 5:09 AM, Peter Levart wrote:
Since I don't know what should be the correct behaviour of javac, I
can leave the Reference.java changes as proposed since it compiles
in both cases. Or should I
On 30/01/2014 14:51, Peter Levart wrote:
I Just commited the version with no change to ReferenceQueueObject
line to jdk9/dev. If there is a bug in javac and the code would not
compile as is, the change to this line should be committed as part of
javac fix, right?
It's good to get this
On 01/28/2014 04:46 PM, Alan Bateman wrote:
On 28/01/2014 08:44, Peter Levart wrote:
Yes, I tried that too and it results in even more unsafe casts.
It's odd yes, since the compile-time error is not present when
building via OpenJDK build system make files (using make images in
top
On 1/29/2014 5:09 AM, Peter Levart wrote:
Since I don't know what should be the correct behaviour of javac, I
can leave the Reference.java changes as proposed since it compiles in
both cases. Or should I revert the change to declaration of local
variable 'q' ?
I slightly prefer to revert
On 01/28/2014 03:17 AM, David Holmes wrote:
On 27/01/2014 5: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
On 28/01/2014 08:44, Peter Levart wrote:
Yes, I tried that too and it results in even more unsafe casts.
It's odd yes, since the compile-time error is not present when
building via OpenJDK build system make files (using make images in
top directory for example) but only if I compile the
On 27/01/2014 5: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
On 1/26/2014 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
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
comments:
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
On 01/24/2014 02:53 AM, srikalyan chandrashekar wrote:
Hi David, yes thats right, only benefit i see is we can avoid
assignment to 'r' if pending is null.
Hi Kalyan,
Good to hear that test runs without failures so far.
Regarding assignment of 'r'. What I tried to accomplish with the change
On 01/22/2014 03:19 AM, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing up the discussion, I propose the following patch for
ReferenceHandler:
http://cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.01/
I can live
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 Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because the r is used later in the code and must not be assigned
pending unless it is not null(this was as is earlier). The new webrev is
posted
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
On 24/01/2014 6:10 AM, srikalyan wrote:
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because the r is used later in the code and must not be assigned
pending unless it is not null(this was as is
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
On 24/01/2014 11:53 AM, srikalyan chandrashekar wrote:
Hi David, yes thats right, only benefit i see is we can avoid assignment
to 'r' if pending is null.
I'm okay with either version.
David
--
Thanks
kalyan
On 1/23/14 4:33 PM, David Holmes wrote:
On 24/01/2014 6:10 AM, srikalyan wrote:
On 21/01/2014 4:54 PM, Peter Levart wrote:
On 01/21/2014 03:22 AM, David Holmes wrote:
Hi Peter,
I do not see Cleaner being loaded prior to the main class on either
Windows or Linux. Which platform are you on? Did you see it loaded
before the main class or as part of executing it?
Before.
Hi, David, Kalyan,
Summing up the discussion, I propose the following patch for
ReferenceHandler:
http://cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.01/
all 10 java/lang/ref tests pass on my PC (including OOMEInReferenceHandler).
I kindly ask Kalyan to try to re-run
On 01/21/2014 08:57 AM, David Holmes wrote:
[Loaded java.util.TimeZone from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
[Loaded sun.util.calendar.ZoneInfo from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
[Loaded sun.util.calendar.ZoneInfoFile from
On 01/21/2014 07:54 AM, Peter Levart wrote:
*[Loaded sun.misc.Cleaner from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]*
[Loaded java.io.ByteArrayInputStream from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
[Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule from
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:
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 ?
The perm gen is not a problem her (JDK 8 does not have it and we see
OOME on JDK8 too). Each time a class is loaded, new
On 22/01/2014 1:24 AM, Peter Levart wrote:
On 01/21/2014 07:54 AM, Peter Levart wrote:
*[Loaded sun.misc.Cleaner from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]*
[Loaded java.io.ByteArrayInputStream from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
[Loaded
On 22/01/2014 8:31 AM, 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 ?
The perm gen is not a problem her (JDK 8 does not have it and we see
OOME on
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing up the discussion, I propose the following patch for
ReferenceHandler:
http://cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.01/
I can live with it, though it maybe that once Cleaner has
On 01/20/2014 02:51 AM, David Holmes wrote:
Hi Peter,
On 17/01/2014 11:24 PM, Peter Levart wrote:
On 01/17/2014 02:13 PM, Peter Levart wrote:
// Fast path for cleaners
boolean isCleaner = false;
try {
isCleaner = r instanceof Cleaner;
} catch (OutofMemoryError oome) {
continue;
}
if
On 01/21/2014 03:22 AM, David Holmes wrote:
Hi Peter,
I do not see Cleaner being loaded prior to the main class on either
Windows or Linux. Which platform are you on? Did you see it loaded
before the main class or as part of executing it?
Before. The main class is empty:
public class Test
Hi Peter,
On 17/01/2014 11:24 PM, Peter Levart wrote:
On 01/17/2014 02:13 PM, Peter Levart wrote:
// Fast path for cleaners
boolean isCleaner = false;
try {
isCleaner = r instanceof Cleaner;
} catch (OutofMemoryError oome) {
continue;
}
if (isCleaner) {
((Cleaner)r).clean();
continue;
On 01/17/2014 05:38 AM, 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.
On 01/17/2014 02:00 PM, Peter Levart wrote:
On 01/17/2014 05:38 AM, 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 01/17/2014 02:13 PM, Peter Levart wrote:
// Fast path for cleaners
boolean isCleaner = false;
try {
isCleaner = r instanceof Cleaner;
} catch (OutofMemoryError oome) {
continue;
}
if (isCleaner) {
((Cleaner)r).clean();
continue;
}
Hi David, Kalyan,
I've caught-up now. Just
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 is
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,
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.
But if the numbers in the dissassembly match
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.
But if
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://bugs.openjdk.java.net/browse/JDK-8022321 as attachments.
Observations from the
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
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 ? If
with,
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 be that fastdebug and/or
On 01/10/2014 12:59 AM, srikalyan chandrashekar wrote:
David/Peter you are right, the logs trace came from passed run, i am
trying to simulate the failure and get the logs for failed runs(2000+
runs done and still no failure), will get back to you once i have the
data from failed run. Sorry
On 01/10/2014 09:31 AM, Peter Levart wrote:
Since we suspect there's something wrong with exception handling in
interpreter, I devised a hypothetical reproducer that tries to
simulate ReferenceHandler in many aspects, but doesn't require to be a
ReferenceHandler:
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
David/Peter you are right, the logs trace came from passed run, i am
trying to simulate the failure and get the logs for failed runs(2000+
runs done and still no failure), will get back to you once i have the
data from failed run. Sorry for the confusion.
---
Thanks
kalyan
On 01/08/2014
On 01/08/2014 07:30 AM, David Holmes 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
Kal,
Can you give access to Peter to the machine where you ran this test. Please
send the details to him privately.
Thanks,
Sandeep
On Jan 8, 2014, at 12:08 PM, srikalyan chandrashekar
srikalyan.chandrashe...@oracle.com wrote:
Hi Peter, the jtreg test configuration is @run main/othervm
Thanks Peter.
Kalyan: Can you confirm, as Peter asked, that the TraceExceptions output
came from a failed run?
AFAICS the Trace info is printed after each bytecode where there is a
pending exception - though I'm not 100% sure on the printing within the
VM runtime. Based on that I think we
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 you been able to reproduce the OOME in that set-up? What was the
result?
Regards, Peter
Peter, getting state info out(to console or otherwise) from within
Reference Handler's exceptions handlers have been unsuccessful. However
David's suggestion produced some useful trace with fast debug build and
could get some information , see the log here
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 thrown, the deepest
call is in
src/share/vm/gc_interface/collectedHeap.inline.hpp, line 157
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 thrown, the deepest
call is in
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
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 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
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),
2. Use UEH(uncaught exception handler per Mandy's inputs)
--
Thanks
kalyan
On 1/6/14 4:40 PM, David Holmes wrote:
Back from vacation ...
On 20/12/2013 4:49 PM,
Hi Mandy, after some trials i could simulate the failure again (now with
UEH in place), however the UEH now cannot print enough details as it
also tries to allocate memory, when it does Thread.getName()(it
internally creates a String object), printStackTrace() also creates new
On 12/23/2013 2:02 PM, srikalyan chandrashekar wrote:
Hi Mandy, after some trials i could simulate the failure again (now
with UEH in place), however the UEH now cannot print enough details as
it also tries to allocate memory, when it does Thread.getName()(it
internally creates a String
On 12/21/2013 8:50 AM, Peter Levart wrote:
Is it possible to get the test output when it fails? It can fail in
two different ways. I can't look at the bug (not authorized)...
You should be able to look at it now. There isn't any other information
besides OOME error.
Exception:
Hi David,
Is it possible to get the test output when it fails? It can fail in two
different ways. I can't look at the bug (not authorized)...
On 12/20/2013 10:54 AM, Chris Hegarty wrote:
On 20 Dec 2013, at 04:33, Mandy Chung mandy.ch...@oracle.com wrote:
Hi Srikalyan,
Maybe you can get
On 20 Dec 2013, at 04:33, Mandy Chung mandy.ch...@oracle.com wrote:
Hi Srikalyan,
Maybe you can get add an uncaught handler to see if you can get
any information.
+1. With this, at least the next time we see this failure we should have a
better idea where the OOM is coming from.
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
Hi Kalyan,
This is not a hotspot issue so I'm moving this to core-libs, please 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
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 Srikalyan,
Maybe you can get add an uncaught handler to see if you can get
any information. I ran it for 1000 times but not able to duplicate
the failure. Did you run it with jtreg (I didn't)?
Below is the patch to install a thread's uncaught handler that
you can take and try.
diff --git
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 causing the
91 matches
Mail list logo