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
Deadlock detection mechanism incorrectly assumes that thread cannot block itself
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. 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
hotspot0.diff
Description: Binary data
/*
* Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 only, as
* published by the Free Software Foundation.
*
* This code is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* version 2 for more details (a copy is included in the LICENSE file that
* accompanied this code).
*
* You should have received a copy of the GNU General Public License version
* 2 along with this work; if not, write to the Free Software Foundation,
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
* or visit www.oracle.com if you need additional information or have any
* questions.
*/
/*
* @test
* @bug TBD
* @summary Enter non-reentrant lock twice, expecting deadlock with a single
thread cycle.
*
* @run main/othervm SelfDeadlockTest
*/
import java.lang.management.*;
import java.util.*;
import java.util.concurrent.*;
import java.util.concurrent.atomic.*;
import java.util.concurrent.locks.*;
public class SelfDeadlockTest implements Runnable {
static FIFOMutex mutex = new FIFOMutex();
public static void main(String... args) throws Exception {
Thread thread = new Thread(new SelfDeadlockTest());
thread.setDaemon(true);
thread.start();
Thread.sleep(1000);
long[] expected = new long[] { thread.getId() };
long[] actual =
ManagementFactory.getThreadMXBean().findDeadlockedThreads();
if (!Arrays.equals(expected, actual)) {
throw new AssertionError("expected: " + Arrays.toString(expected) +
"; actual: " + Arrays.toString(actual));
}
System.out.println("Test passed");
}
public void run() {
mutex.lock();
mutex.lock();
}
}
class FIFOMutex extends AbstractOwnableSynchronizer {
private final AtomicBoolean locked = new AtomicBoolean(false);
private final Queue waiters = new ConcurrentLinkedQueue();
public void lock() {
boolean wasInterrupted = false;
Thread current = Thread.currentThread();
waiters.add(current);
// Block while not first in queue or cannot acquire lock
while (waiters.peek() != current ||
!locked.compareAndSet(false, true)) {
LockSupport.park(this);
if (Thread.interrupted()) // ignore interrupts while waiting
wasInterrupted = true;
}
setExclusiveOwnerThread(current);
waiters.remove();
if (wasInterrupted) // reassert interrupt status on exit
current.interrupt();
}
public void unlock() {
setExclusiveOwnerThread(null);
locked.set(false);
LockSupport.unpark(waiters.peek());
}
}
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
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
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 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 >> <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();
List failed = new ArrayList();
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
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"
> wrote:
>
> > This a simple fix to solve CR 6988220:
> > http://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/
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.
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: 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
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
sun.cpu.isalist
Hi, I can see that such system property as "sun.cpu.isalist" is not set on Linux, but it is set on Solaris and Windows. What is the purpose of this property and shouldn't it be set on Linux as well? Thanks, Dmytro
RE: Excess threads reporting on deadlock
good. thank you 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: Wed, 2 Feb 2011 15:37:11 -0500 Just did now. On Feb 2, 2011, at 3:22 PM, Dmytro Sheyko wrote: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=create&wx_url=/friends.aspx&mkt=en-us>
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=create&wx_url=/friends.aspx&mkt=en-us>
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, I would be very obliged to you if reopen it. Deadlock detection code is used in ThreadMXBean.findDeadlockedThread() and ThreadMXBean.findMonitorDeadlockedThread() (as well as when VM prints out thread information). These JMX methods return ids of deadlocked threads, that is VM actually does some work to provide focused information. And according to javadoc ...a thread is monitor deadlocked if it is part of a cycle in the relation "is waiting for an object monitor owned by"... So, formally, if thread is not in a cycle it is not considered deadlocked and hence should not be return by methods above. I.e. this issue is likely bug than RFE. Also I would like suggest a fix for it https://bugs.openjdk.java.net/show_bug.cgi?id=100065 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=create&wx_url=/friends.aspx&mkt=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=create&wx_url=/friends.aspx&mkt=en-us>
RE: Excess threads reporting on deadlock
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=create&wx_url=/friends.aspx&mkt=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=create&wx_url=/friends.aspx&mkt=en-us>
6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value
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: [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)
> > .
> >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
>
RE: [Fwd: Deadlocked Thread State is RUNNABLE?]
iting threads, 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.()
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.()
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
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. >
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
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
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=create&wx_url=/friends.aspx&mkt=en-us
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/
Cant detect deadlock when thread reenters synchronization block in Object.wait()
Hi, Could you have a look at following patch regarding deadlock detection: Cant detect deadlock when thread reenters synchronization block in Object.wait() https://bugs.openjdk.java.net/show_bug.cgi?id=100058 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6841139 Thank you, Dmytro Sheyko _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx
