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 ]; t
annot 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 its
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 (FIFOMute
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
Th
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
: 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
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.
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
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.j
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
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 exe
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
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
#ifde
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
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
e. 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
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
Subjec
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
rs 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.c
t; 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
> >
> > --
> > Dmyt
k :)
>
> David Holmes (from JavaOne)
>
> Dmytro Sheyko wrote:
> > Hi,
> >
> > Another one patch about deadlock detection:
> >
> > Excess threads reporting on deadlock
> >
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://b
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
o: 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?
>
>
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
/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
>
t 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
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
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
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
30 matches
Mail list logo
