Re: RFR 8244105: JDK 11.0.7 -Xlog gc issue with file path if not exist
Hi, I think it would be very convenient for app developers if JVM were able to create intermediate directories to gc.log file if they do not exist. I.e. $ if [ -f logs/gc.log ]; then echo "log file exists"; else echo "log file does not exist"; fi log file does not exist $ if [ -d logs ]; then echo "log directory exists"; else echo "log directory does not exist"; fi log directory does not exist $ java -Xlog:"gc*:file=logs/gc.log" -version ... $ if [ -d logs ]; then echo "log directory exists"; else echo "log directory does not exist"; fi log directory exists $ if [ -f logs/gc.log ]; then echo "log file exists"; else echo "log file does not exist"; fi log file exists Thanks, Dmytro On Fri, May 8, 2020 at 8:31 PM Harold Seigel wrote: > Hi, > > Please review this fix for JDK-8244105. The fix continues program > execution even when specified logging options are invalid. Previously, > invalid logging options terminated the program. Now, a warning is issued. > For example: > > > java -Xlog:"gc*:file=/dont/exist" -version > [0.001s][error][logging] Error opening log file '/dont/exist': No such > file or directory > [0.001s][error][logging] Initialization of output 'file=/dont/exist' using > options '(null)' failed. > Java HotSpot(TM) 64-Bit Server VM warning: Invalid -Xlog option > '-Xlog:gc*:file=/dont/exist', see error log for details. > > java version "15-internal" 2020-09-15 > Java(TM) SE Runtime Environment (fastdebug build > 15-internal+0-2020-05-08-1313404.hseigel.bug8244105) > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 15-internal+0-2020-05-08-1313404.hseigel.bug8244105, mixed mode, sharing) > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8244105/webrev/index.html > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8244105 > > The fix was regression tested by running Mach5 tiers 1 and 2 tests and > builds on Linux-x64, Solaris, Windows, and Mac OS X and by running Mach5 > tiers 3-5 tests on Linux-x64. > > Thanks, Harold > > >
RE: Deadlock detection mechanism incorrectly assumes that thread cannot block itself
David,
Well, this change is also a bit about code cleanup. Currently we handle cycle
with single thread differently. Why? What is so special about single thread
cycles to ignore them?
Can it be useful not to ignore them and treat as usual thread cycles? I think
yes. For example, one can decide to prefer their own non-reentrant lock to
standard ReentrantLock in order to achieve better performance.
Of course, after the change numerous deadlock cases will still remain
uncovered. And I doubt that all cases will be covered in future. As instance,
AbstractOwnableSynchronizer supports only single owner thread and Thread
supports only single blocker. So the case, where single writer is blocked by
two readers and these readers are both blocked by that writer, cannot be
detected without total rework of deadlock detection code. But the more
problematic cases is covered the better.
Regards,
Dmytro
Date: Wed, 28 Nov 2012 12:53:38 +1000
From: david.hol...@oracle.com
To: dmytro_she...@hotmail.com
CC: hotspot-runtime-...@openjdk.java.net; serviceability-dev@openjdk.java.net
Subject: Re: Deadlock detection mechanism incorrectly assumes that thread
cannot block itself
On 28/11/2012 2:10 AM, Dmytro Sheyko wrote:
Hi,
One more patch regarding deadlock detection.
https://bugs.openjdk.java.net/show_bug.cgi?id=100059
Deadlock detection mechanism assumes that thread cannot block itself. In
general this is not right, especially in case of non-reentrant mutexes.
Arguably that is not a deadlock per se. I'm unclear in your patch as to
what conditions actually constitute a self-deadlock and how it is
detected. For example:
Locksupport.park(); // if no one knows to unpark me I never return
Object o = new Object();
synchronized(o) { o.wait(); } // can't get notified
CountdownLatch l = new CountdownLatch();
l.await(); // no one can count down
Should these be reported? I don't see how they could without much more
elaborate analysis of the objects involved. So what constituates a
detectable self-deadlock?
Thanks,
David
One of such examples we can find here (FIFOMutex sample):
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/LockSupport.html
To fix this, we just need to drop unnecessary code.
Attached updated patch and testcase
Thanks,
Dmytro
Excess threads reporting on deadlock
Hi, I would like to propose a patch regarding deadlock detection. Excess threads reporting on deadlock http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850341 https://bugs.openjdk.java.net/show_bug.cgi?id=100065 Deadlock detection mechanism (ThreadMXBean.findMonitorDeadlockedThreads() and ThreadMXBean.findDeadlockedThreads()) reports not only threads that are involved in deadlock directly, but also some threads that are blocked but out of any deadlock cycle. The idea is to remember the first thread that starts cycle. And start iteration from that leader in places where DeadlockCycle is used to iterate deadlocked threads. Regards, Dmytro hotspot.diff Description: Binary data test.diff Description: Binary data
RE: RFR: 7194254 jstack reports wrong thread priorities
David, Maybe it makes sense to do some little corrections in format specifiers: st-print(# INT64_FORMAT , java_lang_Thread::thread_id(thread_oop)); if (java_lang_Thread::is_daemon(thread_oop)) st-print(daemon ); st-print(prio= INT32_FORMAT , java_lang_Thread::priority(thread_oop)); instead of st-print(#%ld , java_lang_Thread::thread_id(thread_oop)); if (java_lang_Thread::is_daemon(thread_oop)) st-print(daemon ); st-print(prio=%d , java_lang_Thread::priority(thread_oop)); Thanks, Dmytro Date: Fri, 7 Sep 2012 16:54:32 +1000 From: david.hol...@oracle.com To: hotspot-...@openjdk.java.net CC: dmytro_she...@hotmail.com; serviceability-dev@openjdk.java.net Subject: RFR: 7194254 jstack reports wrong thread priorities This is a formal request for review for the patch contributed by Dymtro Sheyko as discussed previously here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-August/006376.html I am one reviewer of course. The webrev is here: http://cr.openjdk.java.net/~dholmes/7194254/webrev.v1/ The fix has two components: 1. It fixes a bug in os::get_priority that assumed a more positive integer was always higher priority than a less positive one. 2. It addresses the problem that os::get_priority is often inexact when desiring the Java thread priority (because the mapping from Java priority to OS priority is often M:1) by not using it in Threads::print_on. Instead Threads::print_on will always report the native OS priority, and JavaThread::print_on() will print the java.lang.Thread.getId() value together with the java.lang.Thread.getPriority() value. This change in output affects all stackdumps including crash logs and thread dumps (including those shown by jstack). There is also a test program to check jstack output. I'll be doing some additional validation while the RFR is in progress. Thanks, David
RE: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value
Prepared test (attached).
Thanks,
Dmytro
Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has
incorrect value
From: staffan.lar...@oracle.com
Date: Thu, 30 Aug 2012 12:06:09 +0200
CC: dmytro_she...@hotmail.com; alan.bate...@oracle.com;
serviceability-dev@openjdk.java.net
To: david.hol...@oracle.com
On 30 aug 2012, at 11:31, David Holmes david.hol...@oracle.com wrote:
On 30/08/2012 5:50 PM, Staffan Larsen wrote:
The patch looks good to me and I can sponsor the push to JDK8-TL.
However, you need a review from an official Reviewer as well.
Reviewed.
Any way we can get a regression test too?
That would be great - I wonder what the test would check, though? That the
value returned is not -1? And hope that sometimes the test will be run on a
machine with 4GB ram.
/Staffan
David
-
BTW, I suggest we remove the confusing comment in
Java_com_sun_management_OperatingSystem_getTotalPhysicalMemorySize()
while we are at it.
/Staffan
On 30 aug 2012, at 09:18, Dmytro Sheyko dmytro_she...@hotmail.com
mailto:dmytro_she...@hotmail.com wrote:
Hi,
Could you please review the patch and apply it if it's correct?
https://bugs.openjdk.java.net/show_bug.cgi?id=100077
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676
Thanks,
Dmytro
Date: Wed, 2 Feb 2011 20:09:59 +1000
From:david.hol...@oracle.com mailto:david.hol...@oracle.com
To:alan.bate...@oracle.com mailto:alan.bate...@oracle.com
CC:dmytro_she...@hotmail.com mailto:dmytro_she...@hotmail.com;
serviceability-dev@openjdk.java.net
mailto:serviceability-dev@openjdk.java.net;hotspot-...@openjdk.java.net
mailto:hotspot-...@openjdk.java.net;core-libs-...@openjdk.java.net
mailto:core-libs-...@openjdk.java.net;jmx-...@openjdk.java.net
mailto:jmx-...@openjdk.java.net
Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize
has incorrect value
Alan Bateman said the following on 02/02/11 20:05:
David Holmes wrote:
It looks like this was actually fixed under 6840305 back in July
2009:
http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300
This CR was not updated however.
Does the problem still exist?
David Holmes
I think this is separate and 6853676 is about
com.sun.management.OperatingSystemMXBean. The code for that is in jdk
repo in src/windows/native/com/sun/management. It should be using
GlobalMemoryStatusEx rather than GlobalMemoryStatus.
Thanks Alan, the comments in 6853676 led me astray.
As a P4 it looks like this has just slipped through the cracks.
David
Dmytro - to your question, serviceability-dev is the right place to
bring it.
-Alan
import java.lang.reflect.Method;
import java.util.Arrays;
import java.util.ArrayList;
import java.util.List;
import java.lang.management.ManagementFactory;
import com.sun.management.OperatingSystemMXBean;
/*
* @bug 6853676
* @summary On computers with more than 4 GB of memory, the GlobalMemoryStatus
function can return incorrect information, reporting a value of 1 to indicate
an overflow.
*/
public class MemoryStatusOverflow {
static final long MEMORYSTATUS_OVERFLOW = (1L 32) - 1; // (DWORD) -1
public static void main(String... args) throws Exception {
OperatingSystemMXBean bean = (OperatingSystemMXBean)
ManagementFactory.getOperatingSystemMXBean();
ListString failed = new ArrayListString();
for (String prop : Arrays.asList(getTotalSwapSpaceSize,
getFreeSwapSpaceSize, getTotalPhysicalMemorySize,
getFreePhysicalMemorySize)) {
Method getter =
OperatingSystemMXBean.class.getMethod(prop);
long value = (Long) getter.invoke(bean);
if (value == MEMORYSTATUS_OVERFLOW) {
failed.add(prop);
}
}
if (!failed.isEmpty()) {
throw new AssertionError(failed);
}
System.out.println(Test passed.);
}
}
RE: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value
Alan, Thank you for your comments. Uploaded corrected version to https://bugs.openjdk.java.net/show_bug.cgi?id=100077 Dmytro Date: Fri, 31 Aug 2012 17:45:47 +0100 From: alan.bate...@oracle.com To: dmytro_she...@hotmail.com CC: serviceability-dev@openjdk.java.net Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value On 31/08/2012 16:55, Dmytro Sheyko wrote: Prepared test (attached). The test code okay to me but it will need a copyright header. Also you will need a @test tag so that it run by jtreg. I think it's more normal to put this before the imports. Finally, I think it would be good to get the indentation consistent, looks like you are using 8-spaces instead of 4. Otherwise it is good to finally get this issue fixed. -Alan
RE: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value
Hi, Could you please review the patch and apply it if it's correct? https://bugs.openjdk.java.net/show_bug.cgi?id=100077 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676 Thanks, Dmytro Date: Wed, 2 Feb 2011 20:09:59 +1000 From: david.hol...@oracle.com To: alan.bate...@oracle.com CC: dmytro_she...@hotmail.com; serviceability-dev@openjdk.java.net; hotspot-...@openjdk.java.net; core-libs-...@openjdk.java.net; jmx-...@openjdk.java.net Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value Alan Bateman said the following on 02/02/11 20:05: David Holmes wrote: It looks like this was actually fixed under 6840305 back in July 2009: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 This CR was not updated however. Does the problem still exist? David Holmes I think this is separate and 6853676 is about com.sun.management.OperatingSystemMXBean. The code for that is in jdk repo in src/windows/native/com/sun/management. It should be using GlobalMemoryStatusEx rather than GlobalMemoryStatus. Thanks Alan, the comments in 6853676 led me astray. As a P4 it looks like this has just slipped through the cracks. David Dmytro - to your question, serviceability-dev is the right place to bring it. -Alan
com.sun.management.VMOption.toString()
Hi, Just found little misprint in com.sun.management.VMOption.toString() It returns ...(read-only) if writable is true and ...(read-write) otherwise. Here is a patch: diff -r 156ab3c38556 src/share/classes/com/sun/management/VMOption.java --- a/src/share/classes/com/sun/management/VMOption.javaThu Aug 23 12:27:49 2012 -0700 +++ b/src/share/classes/com/sun/management/VMOption.javaMon Aug 27 18:52:10 2012 +0300 @@ -178,7 +178,7 @@ return VM option: + getName() + value: + value + + origin: + origin + + - (writeable ? (read-only) : (read-write)); + (writeable ? (read-write) : (read-only)); } /** Do we need formal bug report to fix this? Regards, Dmytro
RE: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale
Hi,
Though compareTo tends to be less efficient than equals, it offers better
type safety.
When we (mistakenly!) compare objects of different type, equals silently
accepts parameter of wrong type,
but returns false. Comparison with compareTo is rejected by compiler.
Consider,
String string = ...
Date date = ...
if (string.equals(date)) { // always false
}
if (string.compareTo(date) == 0) { // compilation error
}
Regards,
Dmytro
Date: Thu, 23 Feb 2012 10:58:47 -0500
Subject: Re: RFR: 6988220: java.lang.ObjectName use of String.intern() causes
major performance issues at scale
From: vita...@gmail.com
To: frederic.par...@oracle.com
CC: serviceability-dev@openjdk.java.net; core-libs-...@openjdk.java.net
Hi Frederic,
Just curious - why are you checking string equality via compareTo() instead
of equals()?
Thanks
Sent from my phone
On Feb 23, 2012 10:37 AM, Frederic Parain frederic.par...@oracle.com
wrote:
This a simple fix to solve CR 6988220:
http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6988220http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220
The use of String.intern() in the ObjectName class prevents
the class the scale well when more than 20K ObjectNames are
managed. The fix simply removes the use of String.intern(),
and uses regular String instead. The Object.equals() method
is modified too to make a regular String comparison. The
complexity of this method now depends on the length of
the ObjectName's canonical name, and is not impacted any
more by the number of ObjectName instances being handled.
The Webrev:
http://cr.openjdk.java.net/~**fparain/6988220/webrev.00/http://cr.openjdk.java.net/~fparain/6988220/webrev.00/
I've tested this fix with the jdk_lang and jdk_management
test suites.
Thanks,
Fred
--
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: frederic.par...@oracle.com
Attaching to local JVM on Windows
Hi,
On Windows x64 such tools as jconsole are unable to connect to 32bit JVM if
they are launched on 64bit JVM and vice versa (32bit JVM can't attach 64bit
JVM).
Trying to figure out the reason not to attach JVM of different bitness, I can
see that connection is done by injecting some native piece of code to target
JVM.
jdk/src/windows/native/sun/tools/attach/WindowsVirtualMachine.c
Why did we follow this way? Wouldn't it be simpler and better to use, for
example, named pipe with name like \\.\pipe\java_pid${pid}, which target JVM
would create during initialization and then read; and attaching JVM would just
send commands to?
Thanks,
Dmytro
RE: Attaching to local JVM on Windows
Thanks Alan, Unfortunately, I can't see this bug report. I seems it isn't available for public. Date: Wed, 23 Mar 2011 17:00:23 + From: alan.bate...@oracle.com To: dmytro_she...@hotmail.com CC: serviceability-dev@openjdk.java.net Subject: Re: Attaching to local JVM on Windows Dmytro Sheyko wrote: Hi, On Windows x64 such tools as jconsole are unable to connect to 32bit JVM if they are launched on 64bit JVM and vice versa (32bit JVM can't attach 64bit JVM). This is tracked as 6277710. One suggested approach is a provider that uses a helper executable and the existing mechanism rather than creating a new mechanism, it's just that nobody ever got to implementing it. -Alan.
RE: sun.cpu.isalist
Hi,
I have tried 1.7.0-ea-b129 and 1.6.0_24-b07 on Solaris 11 and they both have
shown empty sun.cpu.isalist.
At the same time isalist output is: amd64 pentium_pro+mmx pentium_pro
pentium+mmx pentium i486 i386 i86
The code that fills sun.cpu.isalist on Soliaris/Linux is following
#ifdef SI_ISALIST
/* supported instruction sets */
{
char list[258];
sysinfo(SI_ISALIST, list, sizeof(list));
sprops.cpu_isalist = strdup(list);
}
#else
sprops.cpu_isalist = NULL;
#endif
and in order to use sysinfo(SI_ISALIST) API we have to include header
#include sys/systeminfo.h
However this header is not included in java_props_md.c!
So, neither Solaris nor Linux fills sun.cpu.isalist. Only Windows does.
But again Windows does this slightly differently. It shows
amd64 on 64bit jre and
pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 on 32bit.
I can find only this bug report, which is likely related to the issue.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6340855
sun.cpu.isalist property is empty in jinfo
It seems that this property hasn't been not filled properly so long. Is it hard
drop it at all?
Thanks,
Dmytro
Date: Tue, 15 Feb 2011 10:00:09 +
From: alan.bate...@oracle.comt
To: david.hol...@oracle.com
CC: dmytro_she...@hotmail.com; serviceability-dev@openjdk.java.net;
core-libs-...@openjdk.java.net
Subject: Re: sun.cpu.isalist
David Holmes wrote:
:
I don't see the property actually being used anywhere these days. No
idea what it may have been used for other than printing the property
for information (there's a Java2D demo that does that).
Is there an API on Linux that will provide the information? Both
Solaris and Windows have a sys info call that can provide this
information. But Linux sysinfo is something different.
I checked the pre-OpenJDK history and it seems to have been added in
1999 without explanation. I can only guess that it was something added
for some Solaris service. It doesn't appear to have ever been documented
and I doubt it is used.
-Alan
RE: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value
Hi, Any updates on it? I don't want to be overly importunate, but the quite trivial fix was available year ago. Maybe I do something wrong, so please suggest what I should do to have this bug fixed. Thanks, Dmytro From: dmytro_she...@hotmail.com To: serviceability-dev@openjdk.java.net Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value Date: Fri, 28 Jan 2011 15:05:45 +0700 Hi, I would like to find sponsor and discuss fix for bug#6853676 OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676 The idea is to use GlobalMemoryStatusEx instead of GlobalMemoryStatus. patch is available here: https://bugs.openjdk.java.net/show_bug.cgi?id=100077 Thanks, Dmytro
RE: Excess threads reporting on deadlock
Keith, Have you tried to re-open the bug? I can't see changes in its status. Thanks, Dmytro CC: david.hol...@sun.com; serviceability-dev@openjdk.java.net From: keith.mcgui...@oracle.com To: dmytro_she...@hotmail.com Subject: Re: Excess threads reporting on deadlock Date: Mon, 31 Jan 2011 11:09:13 -0500 You'll have to excuse me while I struggle to remember the details of this one, but I believe that the deadlock detection code in the VM only detects the existence of a deadlock when it happens, but it doesn't know which threads are a part of it. Any thread that is currently blocked is a potential contributor to the deadlock, so the VM prints out information about all the blocked threads so that the developer can determine where the deadlock is and how to fix it. I could be wrong about this -- it's been a while since I looked at it. Again, IMO, this ought to be fine, but I understand if you've got lots of blocked threads than you might have a lot of extra data to slog through. I can re-open the bug if you like (perhaps as an RFE?), but it's not likely to be a high enough priority to be fixed anytime in the near future. Unless someone wants to investigate the code to find and suggest a fix (hint, hint). --- Keith On Jan 31, 2011, at 10:20 AM, Dmytro Sheyko wrote:Hi Keith, Thank you for information about this bug. May I convince you of the need for fixing it? The more the better approach does not go well here. Doesn't it make sense to report all threads (including even not blocked ones)? Analyzing deadlock it's important to know threads that form cycle. The problem is almost always in code that these threads execute. Other threads just hinder analysis. But if I need them I can use other API that gives me the list of all threads. However, existing behavior does not even follow the more the better approach properly. Sometimes the deadlock is reported as (A, B, C), sometimes as (B, C, D) and as (B, С), but never as (A, B, C, D). The set of threads that are reported is not clearly defined. Thanks, Dmytro CC: david.hol...@sun.com; serviceability-dev@openjdk.java.net From: keith.mcgui...@oracle.com To: dmytro_she...@hotmail.com Subject: Re: Excess threads reporting on deadlock Date: Mon, 31 Jan 2011 07:57:00 -0500 Hi Dmytro - This bug was marked 'closed' because the behavior noted is intentional and we do not believe it should be changed. When an error situation such as a deadlock occurs we want the developer to have as much information as possible to help resolve the issue. --- Keith On Jan 31, 2011, at 4:52 AM, Dmytro Sheyko wrote:Corrections: I am about this one: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850341 From: dmytro_she...@hotmail.com To: david.hol...@sun.com Subject: RE: Excess threads reporting on deadlock Date: Mon, 31 Jan 2011 16:48:55 +0700 CC: serviceability-dev@openjdk.java.net Hi, I just noticed that the bug report is closed. Can I know why? Thanks, Dmytro Date: Fri, 5 Jun 2009 03:41:17 +1000 From: david.hol...@sun.com Subject: Re: Excess threads reporting on deadlock To: dmytro_she...@hotmail.com CC: serviceability-dev@openjdk.java.net Hi Dmytro, Thanks for submitting these. I just wanted to say that a lack of immediate response on the mailing lists does not mean noone is, or will, look at these, but it may be a while before people have the cycles to do so. Certainly this week is not a good week :) David Holmes (from JavaOne) Dmytro Sheyko wrote: Hi, Another one patch about deadlock detection: Excess threads reporting on deadlock https://bugs.openjdk.java.net/show_bug.cgi?id=100065 -- Dmytro Sheyko Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us
RE: Excess threads reporting on deadlock
Hi, I just noticed that the bug report is closed. Can I know why? Thanks, Dmytro Date: Fri, 5 Jun 2009 03:41:17 +1000 From: david.hol...@sun.com Subject: Re: Excess threads reporting on deadlock To: dmytro_she...@hotmail.com CC: serviceability-dev@openjdk.java.net Hi Dmytro, Thanks for submitting these. I just wanted to say that a lack of immediate response on the mailing lists does not mean noone is, or will, look at these, but it may be a while before people have the cycles to do so. Certainly this week is not a good week :) David Holmes (from JavaOne) Dmytro Sheyko wrote: Hi, Another one patch about deadlock detection: Excess threads reporting on deadlock https://bugs.openjdk.java.net/show_bug.cgi?id=100065 -- Dmytro Sheyko Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us
RE: Excess threads reporting on deadlock
Hi Keith, Thank you for information about this bug. May I convince you of the need for fixing it? The more the better approach does not go well here. Doesn't it make sense to report all threads (including even not blocked ones)? Analyzing deadlock it's important to know threads that form cycle. The problem is almost always in code that these threads execute. Other threads just hinder analysis. But if I need them I can use other API that gives me the list of all threads. However, existing behavior does not even follow the more the better approach properly. Sometimes the deadlock is reported as (A, B, C), sometimes as (B, C, D) and as (B, С), but never as (A, B, C, D). The set of threads that are reported is not clearly defined. Thanks, Dmytro CC: david.hol...@sun.com; serviceability-dev@openjdk.java.net From: keith.mcgui...@oracle.com To: dmytro_she...@hotmail.com Subject: Re: Excess threads reporting on deadlock Date: Mon, 31 Jan 2011 07:57:00 -0500 Hi Dmytro - This bug was marked 'closed' because the behavior noted is intentional and we do not believe it should be changed. When an error situation such as a deadlock occurs we want the developer to have as much information as possible to help resolve the issue. --- Keith On Jan 31, 2011, at 4:52 AM, Dmytro Sheyko wrote:Corrections: I am about this one: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850341 From: dmytro_she...@hotmail.com To: david.hol...@sun.com Subject: RE: Excess threads reporting on deadlock Date: Mon, 31 Jan 2011 16:48:55 +0700 CC: serviceability-dev@openjdk.java.net Hi, I just noticed that the bug report is closed. Can I know why? Thanks, Dmytro Date: Fri, 5 Jun 2009 03:41:17 +1000 From: david.hol...@sun.com Subject: Re: Excess threads reporting on deadlock To: dmytro_she...@hotmail.com CC: serviceability-dev@openjdk.java.net Hi Dmytro, Thanks for submitting these. I just wanted to say that a lack of immediate response on the mailing lists does not mean noone is, or will, look at these, but it may be a while before people have the cycles to do so. Certainly this week is not a good week :) David Holmes (from JavaOne) Dmytro Sheyko wrote: Hi, Another one patch about deadlock detection: Excess threads reporting on deadlock https://bugs.openjdk.java.net/show_bug.cgi?id=100065 -- Dmytro Sheyko Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us
RE: [Fwd: Deadlocked Thread State is RUNNABLE?]
Thank you, David.
I agree with you that proposed change would lead to race condition. I wonder,
is this possible to avoid deadlocks in class
initialization without sacrifice to performance?
As for poor design, sometimes base class may cause its subclass initialization.
For example,
enum Base {
DERIVED {};
}
Of cource, it's safe in the case of possible deadlocks. But anyway, I believe
that runtime should get round possible problems,
if it's possible and not hard to do. Even if it is really bad design, it
shouldn't worsen the situation falling into deadlock.
Date: Wed, 25 Nov 2009 10:41:23 +1000
From: david.hol...@sun.com
Subject: Re: [Fwd: Deadlocked Thread State is RUNNABLE?]
To: dmytro_she...@hotmail.com
CC: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net
Dmytro,
Okay I see what you mean. However I'm more inclined to go with a design
that benefits normal correct usage than to avoid a deadlock caused by
poor design: a Base class should never depend on its subclasses during
initialization.
With the change you suggest, two threads trying to initialize the same
class will race each other to the top of the hierarchy (or the first
uninitialized class anyway) where one will perform the clinit and the
other will wait. When clinit is done the waiting thread will be
signalled and wakeup, both threads then race to initialize the next
subclass - one will win and one will wait ... this process then
continues down the hierarchy with the two threads butting heads at
every step of the way. This is potentially a very wasteful process.
Of course I can't speak to the original design and what considerations
were made at that time - I wasn't there. This is just my opinion.
Cheers,
David Holmes
Dmytro Sheyko said the following on 11/24/09 23:00:
David,
The lock of the class is not held during its own or its superclass's
Yes, I know. I mean, let's say, artifical lock that prevents
simultaneous class initialization from different threads.
The current scheme of class initialization is following:
1. Synchronize on the |Class| object that represents the class or
interface to be initialized. This involves waiting until the
current thread can obtain the lock for that object (§8.13)
file:///C:/Tools/Java/docs/vmspec.2nded/Threads.doc.html#22500.
2. If initialization by some other thread is in progress for the
class or interface, then |wait| on this |Class| object (which
temporarily releases the lock). When the current thread awakens
from the |wait|, repeat this step.
3. If initialization is in progress for the class or interface by the
current thread, then this must be a recursive request for
initialization. Release the lock on the |Class| object and
complete normally.
4. If the class or interface has already been initialized, then no
further action is required. Release the lock on the |Class| object
and complete normally.
5. If the |Class| object is in an erroneous state, then
initialization is not possible. Release the lock on the |Class|
object and throw a |NoClassDefFoundError|.
6. Otherwise, record the fact that initialization of the |Class|
object is now in progress by the current thread and release the
lock on the |Class| object.
7. Next, if the |Class| object represents a class rather than an
interface, and the direct superclass of this class has not yet
been initialized, then recursively perform this entire procedure
for the uninitialized superclass. If the initialization of the
direct superclass completes abruptly because of a thrown
exception, then lock this |Class| object, label it erroneous,
notify all waiting threads, release the lock, and complete
abruptly, throwing the same exception that resulted from the
initializing the superclass.
8. Next, execute either the class variable initializers and static
initializers of the class or the field initializers of the
interface, in textual order, as though they were a single block,
except that |final| |static| variables and fields of interfaces
whose values are compile-time constants are initialized first.
9. If the execution of the initializers completes normally, then lock
this |Class| object, label it fully initialized, notify all
waiting threads, release the lock, and complete this procedure
normally.
10. Otherwise, the initializers must have completed abruptly by
throwing some exception E. If the class of E is not |Error| or one
of its subclasses, then create a new instance of the class
|ExceptionInInitializerError|, with E as the argument, and use
this object in place of E in the following step. But if a new
instance
RE: [Fwd: Deadlocked Thread State is RUNNABLE?]
Hi, BTW, What is the reason to hold lock on class being initialized while initializing its superclasses? Wouldn't it better acquire lock after superclass initialization just before calling static initializer? This would prevents some kind of deadlocks. Thanks, Dmytro Date: Wed, 18 Nov 2009 11:58:18 +1000 From: david.hol...@sun.com Subject: Re: [Fwd: Deadlocked Thread State is RUNNABLE?] To: mandy.ch...@sun.com CC: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Mandy Chung said the following on 11/18/09 11:36: It's a known bug: 6501158: Thread state is incorrect during class initialization procedure I recalled the discussion for this bug but don't remember if we discussed enhancing the java.lang.management spec to cover waiting on VM internal actions. David will probably have more information about this. I have nothing really to add save what is stated in the CR, but as my main comment was not public I've moved it to being public (and dropped myself as RE) and reproduce it below. Quite simply the code that does the wait is low-level in the VM and does not come through the normal Object.wait() path that would set the Thread.State. It can be fixed but there are a couple of additional issues that also need to be addressed due to the fact that the monitor used is not associated with Java-level object. (The JLS was updated in this regard.) The meta-discussion was whether we should introduce a new Thread.State to cover this special case (waiting for class initialization), and that discussion seemed to lean towards doing this (I suggested it and Mandy agreed it seemed like a good idea :) ) But things did not progress from there. Cheers, David - From 6501158: The submitter quotes the JLS with regard to the class initialization procedure and how synchronization is employed. In fact hotspot does not synchronize using the Class object monitor during class initialization - this is to avoid denial-of-service style attacks just by explicitly locking a Class object. The JLS is in the process of being updated to say that a unique initialization lock is used for class initialization, not necessarily the Class object's lock. This brings the spec into line with the hotspot implementation. The reason I mention this is that the monitor that hotspot uses is associated with the klassOop for the class. The monitor code sets current_waiting_monitor() or current_pending_monitor() as appropriate during wait() or monitor entry. The management code, via the ThreadService::ThreadSnapShot gets a hold of the object associated with the monitor for a blocked thread and assumes that the object is in fact the oop for a java.lang.Object. When the klassOop is treated as in instance oop and queried for its own class etc then we end up crashing the VM. The suggested fix correctly sets the thread state to WAITING: Full thread dump Java HotSpot(TM) Tiered VM (1.7.0-internal-dh198349-fastdebug mixed mode): Runner prio=3 tid=0x08171800 nid=0xb in Object.wait() [0xcb99d000..0xcb99dbb0] java.lang.Thread.State: WAITING (on object monitor) but additional changes are need in ThreadSnapShot to discard the non-instance oop. (It seems JvmtiEnvBase::get_current_contended_monitor would need a similar modification). This seems to work and getThreadInfo simply reports eg: Current thread info: Runner Id=8 WAITING which seems okay. And getLockInfo() returns null. It is unclear however whether reporting this information actually violates the specification for these management API's. A thread is only WAITING when performing Object.wait(), in which case there must be an Object being waited upon and so LockInfo must return non-null information. Yet that is not the case here. It seems to me that while we can report the information above, it might be better to see whether the management specification can be enhanced to cover waiting on VM internal actions and to then report this circumstance as one of those. Note also that the existing hotspot code could already be susceptible to a crash due to the use of the klassOop monitor for class initialization. If the timing were just right, a call to getThreadInfo could see a thread blocked trying to acquire this monitor (not wait upon it) and that would be captured by the ThreadSnapshot and eventually cause a crash. The fact that the snapshot requires a safepoint makes it less likely that you would encounter the target thread while blocked on the monitor, as the monitor is only held for a short period during class initialization. I will await discussion with the management/monitoring folk before deciding how best to proceed with this CR. _ Windows Live: Keep your friends up to date with what
RE: [Fwd: Deadlocked Thread State is RUNNABLE?]
, release the
lock, and complete this procedure normally.
Otherwise, the initializers must have completed abruptly by throwing some
exception E. If the class of E is not Error or one of its subclasses, then
create a new instance of the class ExceptionInInitializerError, with E as the
argument, and use this object in place of E in the following step. But if a new
instance of ExceptionInInitializerError cannot be created because an
OutOfMemoryError occurs, then instead use an OutOfMemoryError object in place
of E in the following step.
Lock the Class object, label it erroneous,
notify all waiting threads, release the lock, and complete this
procedure abruptly with reason E or its replacement as determined in
the previous step.
Consider example:
class Base {
static {
DerivedB.init();
}
}
class DerivedA extends Base {}
class DerivedB extends Base {}
ThreadA initializes DerivedA
ThreadB initializes DerivedB
Existing scheme scenario:
1. ThreadA marks DerivedA as being initialized by it (i.e. ThreadA).
2. ThreadB marks DerivedB as being initialized by it (i.e. ThreadB).
3. ThreadA starts initialization of class Base.
4. ThreadB attempts to initialize class Base and waits for ThreadA.
5. ThreadA invokes Base.clinit()
6. ThreadA attempts to initialize class DerivedB and waits for ThreadB
(triggered by static method call).
-- deadlock.
New scheme scenario:
1. ThreadA starts initialization of class Base (superclass of DerivedA);
2. ThreadB attempts to initialize class Base and waits for ThreadA.
3. ThreadA invokes Base.clinit()
4. ThreadA starts initialization of class DerivedB (triggered by static method
call)
5. ThreadA starts initialization of class Base and it figures out that is
already being initialized by it - normal completion.
6. ThreadA marks DerivedB as initialized;
7. ThreadA marks Base as initialized;
8. ThreadB wakes up and figures out that Base is already initialized;
9. ThreadB figures out that DerivedB is already initialized;
10. ThreadA marks DerivedA as initialized;
--
Dmytro
Date: Tue, 24 Nov 2009 20:05:26 +1000
From: david.hol...@sun.com
Subject: Re: [Fwd: Deadlocked Thread State is RUNNABLE?]
To: dmytro_she...@hotmail.com
CC: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net
Dmytro Sheyko said the following on 11/24/09 19:42:
What is the reason to hold lock on class being initialized while
initializing its superclasses?
The lock of the class is not held during its own or its superclass's
initialization. A lock is only used to set the current class as
being-initialized, and for concurrent initialization attempts to be able
to wait.
David Holmes
Wouldn't it better acquire lock after superclass initialization just
before calling static initializer?
This would prevents some kind of deadlocks.
Thanks,
Dmytro
Date: Wed, 18 Nov 2009 11:58:18 +1000
From: david.hol...@sun.com
Subject: Re: [Fwd: Deadlocked Thread State is RUNNABLE?]
To: mandy.ch...@sun.com
CC: serviceability-dev@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Mandy Chung said the following on 11/18/09 11:36:
It's a known bug:
6501158: Thread state is incorrect during class initialization
procedure
I recalled the discussion for this bug but don't remember if we
discussed enhancing the java.lang.management spec to cover waiting
on VM internal actions.
David will probably have more information about this.
I have nothing really to add save what is stated in the CR, but as my
main comment was not public I've moved it to being public (and dropped
myself as RE) and reproduce it below.
Quite simply the code that does the wait is low-level in the VM and
does not come through the normal Object.wait() path that would set the
Thread.State. It can be fixed but there are a couple of additional
issues that also need to be addressed due to the fact that the monitor
used is not associated with Java-level object. (The JLS was updated in
this regard.)
The meta-discussion was whether we should introduce a new Thread.State
to cover this special case (waiting for class initialization), and that
discussion seemed to lean towards doing this (I suggested it and Mandy
agreed it seemed like a good idea :) ) But things did not progress from
there.
Cheers,
David
-
From 6501158:
The submitter quotes the JLS with regard to the class initialization
procedure and how synchronization is employed. In fact hotspot does not
synchronize using the Class object monitor during class initialization -
this is to avoid denial-of-service style attacks just by explicitly
locking a Class object. The JLS is in the process of being updated to
say that a unique initialization lock is used for class
initialization, not necessarily the Class object's lock. This brings
RE: hg: jdk7/hotspot-rt/hotspot: 6840305: Discrepancy in system memory details (when 4G or greater) reported by JVM and Windows OS
Hi, I would note that this is not the only place where GlobalMemoryStatus() is used instead of GlobalMemoryStatusEx(). Please have a look at OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676 https://bugs.openjdk.java.net/show_bug.cgi?id=100077 Hope that due to similarity with the former one, this bug has a chance to be fixed soon as well. -- Dmytro Sheyko From: poonam.ba...@sun.com To: jdk7-chan...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: hg: jdk7/hotspot-rt/hotspot: 6840305: Discrepancy in system memory details (when 4G or greater) reported by JVM and Windows OS Date: Fri, 17 Jul 2009 14:39:46 + Changeset: 8c79517a9300 Author:poonam Date: 2009-07-16 18:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 6840305: Discrepancy in system memory details (when 4G or greater) reported by JVM and Windows OS Summary: GlobalMemoryStatus() does not report correct memory usage when the system has more than 4gb of RAM. GlobalMemoryStatusEx() should be used in place of GlobalMemoryStatus(). Reviewed-by: kamg, coleenp ! src/os/windows/vm/os_windows.cpp _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx
Excess threads reporting on deadlock
Hi, Another one patch about deadlock detection: Excess threads reporting on deadlock https://bugs.openjdk.java.net/show_bug.cgi?id=100065 -- Dmytro Sheyko _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us
RE: Excess threads reporting on deadlock
I see. Never mind. Date: Fri, 5 Jun 2009 03:41:17 +1000 From: david.hol...@sun.com Subject: Re: Excess threads reporting on deadlock To: dmytro_she...@hotmail.com CC: serviceability-dev@openjdk.java.net Hi Dmytro, Thanks for submitting these. I just wanted to say that a lack of immediate response on the mailing lists does not mean noone is, or will, look at these, but it may be a while before people have the cycles to do so. Certainly this week is not a good week :) David Holmes (from JavaOne) Dmytro Sheyko wrote: Hi, Another one patch about deadlock detection: Excess threads reporting on deadlock https://bugs.openjdk.java.net/show_bug.cgi?id=100065 _ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx
Deadlock detection mechanism incorrectly assumes that thread cannot block itself
Hi, One more regarding deadlock detection: Deadlock detection mechanism incorrectly assumes that thread cannot block itself https://bugs.openjdk.java.net/show_bug.cgi?id=100059 -- Dmytro Sheyko _ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/
