Joseph Shraibman wrote:
Thread.yield() is used under two different scenarios:
+ waiting for certain condition to become true (or false), most
likely this is used in a yield loop, and current thread has
nothing to do but burning CPU cycles in a while loop.
+ be nice and let kernel/pthr
Joseph Shraibman wrote:
Alexander V. Konstantinou wrote:
Actually, thread priorities work fine in Linux.
No, they don't, not with the latest sun jdk on redhat 8.0.
Thread priority is just a hint (same applies to Thread.yield()).
It's up to the underlying system (in this case, the Linux ker
Joseph Shraibman wrote:
Hui Huang wrote:
Joseph Shraibman wrote:
Alexander V. Konstantinou wrote:
Actually, thread priorities work fine in Linux.
No, they don't, not with the latest sun jdk on redhat 8.0.
Thread priority is just a hint (same applies to Thread.yield()).
Whil
Joseph Shraibman wrote:
Juergen Kreileder wrote:
[EMAIL PROTECTED] writes:
On Fri, 14 Feb 2003, Juergen Kreileder wrote:
BTW: If you use another setting than CONFIG_1GB
or if you're on x86-64
you want to use the new release. Older HotSpot versions have
problems with the other values.
So
Christopher Smith wrote:
On Tue, 2003-06-03 at 19:29, John Neffenger wrote:
Hi Bill,
Also, 2.5.x Linux has changes to their 1:1 model that greatly increases
scalability for dealing with a large number of threads.
I was under the impression that Java application developers will have to
wait for
John Neffenger wrote:
Hi Bill,
Also, 2.5.x Linux has changes to their 1:1 model that greatly increases
scalability for dealing with a large number of threads.
I was under the impression that Java application developers will have to
wait for the Java virtual machines to take advantage of those t
Christopher Smith wrote:
Juergen Kreileder wrote:
Christopher Smith <[EMAIL PROTECTED]> writes:
On Tue, 2003-06-03 at 19:29, John Neffenger wrote:
Hi Bill,
Also, 2.5.x Linux has changes to their 1:1 model that greatly
increases scalability for dealing with a large number of thread
Nathan Bryant wrote:
Daniel Malmkvist wrote:
To my supprise i could not have more then ~3500 threads at the same time.
I got a OutOfMemoryException, but there was plenty of system memory left
(the JVM only ha about 10% of system physical memory).
Address space might be a limiting factor in a 32
Vincent Touquet wrote:
On Wed, Feb 04, 2004 at 09:56:57AM -0800, Hui Huang wrote:
Default stack size is 512k. You need 3500 * 512k = 1750M address space
for 3500 threads. Try -Xss96k. Also check your limit on max #processes
(ulimit -u), you can't create more threads than that limit either.
JVM fataled because it's an irrecoverable error (i.e. not as
simple as StackOverflowError).
Prior to 1.5, Sun's JDK needs to allocate alternate signal stack
to handle stack overflows. For compatibility reasons, the alt
stack is actually allocated within the normal thread stack. If a
thread (either
llocate the alt stack because we just had a stack overflow
Hui Huang wrote:
JVM fataled because it's an irrecoverable error (i.e. not as
simple as StackOverflowError).
Prior to 1.5, Sun's JDK needs to allocate alternate signal stack
to handle stack overflows. For compatibility reasons,
Hi Nicole,
I tested your code. It works fine on my machine with 2.6.4. I
tested Sun JDK 1.3.1fcs, 1.3.1_10, 1.3.1_11, 1.4.2fcs, 1.4.2_03
and 1.5beta. SignalTest is able to catch HUP, TERM, INT.
That said, I'd like to point out that the Java level signal API
is private interface. Its sole purpose i
The segfault messages look benign - they are the implicit NULL checks
within JVM.
Did you see a hang or a crash (i.e. tomcat process is gone,
segfaults in kernel log don't count, they are handled by JVM)?
Is this on HT Xeon? I've heard 2.6.5 in FC2 is not stable (frequent
hang) but 2.6.6 is Ok, loo
Joseph Shraibman wrote:
Does the sun version make the call? Does blackdown? Just curious, it
doesn't appear as if it will matter any time soon :(
Sun JVM does call pthread_setschedparam(), but of course this wouldn't
make any difference ...
Thread priority is one of the scheduling issues that h
Is this on Redhat 9? If so, try this:
+ find out java process id
+ use gdb to attach to the process (gdb - )
+ quit gdb
wait a few seconds, does the process start to run again? If yes,
it's a known RH-9 issue (a notification from pthread_cond_broadcast
is lost in NPTL). Update to AS-3 or set LD_ASS
ess still hangs after attach-detach
with gdb, it's something else.
Reg
Veda
-Original Message-
From: Hui Huang [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 24, 2004 10:39 AM
To: Joseph Shraibman
Cc: [EMAIL PROTECTED]; Veda N Ponnusamy; [EMAIL PROTECTED]
Subject: Re: Help on JVM hang
Is
Joseph Shraibman wrote:
Hui Huang wrote:
Veda N Ponnusamy wrote:
Hi,
We set the LD_ASSUME_KERNEL=2.2.5 and the hang goes away. But the
application
is running at 60% speed !!
Interesting. You could try LD_ASSUME_KERNEL=2.4.1 (the floating
stack version of LinuxThreads), it's generally f
Joseph Shraibman wrote:
Hui Huang wrote:
Is this on Redhat 9? If so, try this:
+ find out java process id
+ use gdb to attach to the process (gdb - )
+ quit gdb
wait a few seconds, does the process start to run again? If yes,
it's a known RH-9 issue (a notification from pthread_cond_broadca
That sounds like an OS issue. A user application such as Java does not
have the power to take down the whole system.
BTW, if you believe the issue is in Sun JDK, you should definitely
file a bug with Sun. Sorry to hear your past experience isn't good,
sometimes a bug is given a low priority due to
19 matches
Mail list logo
