Native Threads Help
I just installed the native threads add-on to the 1.1.7 JRE and whenever I try to use it (jre -native test) I get the following result: Cannot open /proc/02891 for GCCould not create Java VM Where the proc number changes every time... I'm using Red Hat 6.1 on a 2-processor system. Any thoughts would be appreciated. Thanks, Aaron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Native Threads Help
Aaron Mulder wrote: > > I just installed the native threads add-on to the 1.1.7 JRE and > whenever I try to use it (jre -native test) I get the following result: > > Cannot open /proc/02891 for GCCould not create Java VM > > Where the proc number changes every time... I'm using Red Hat > 6.1 on a 2-processor system. Any thoughts would be appreciated. Looks like libjava has some dependencies on the Linux /proc filesystem. What do you see when you look in the /proc directory? If nothing (or the directory doesn't exist), I'd say you've got a Linux that isn't configured to support the /proc filesystem. That's a pretty strange configuration, so my next question would be how you obtained your Linux kernel. Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Benchmark results for Linux JVMs (formatted for 70 columns)
>
> Personally, I'd be interested to see info about non-Blackdown free
> JVMs. We don't hear too much about them on this list. That would
> have been an interesting comparison.
>
I ran the JVMSpec98 benchmarks from the cmdline to see how Kaffe
measures up against other JVMs.
Here's the estimates I got; they're all in seconds, lower is better:
compress jess db javac mpegaudio mtrt jack
ibmjdk 32.13 52.48 64.59 62.41 26.61 37.39 32.13
msjvm 33.90 51.40129.00 84.50 41.00 24.90 65.10
sun1.1.832.50 35.10108.00 117.00 30.30 58.40 42.20
jdk1.2 76.41 69.32158.47 111.12 60.66 62.10 83.15
Kaffe/jit3 47.54 104.33 98.49 111.99 91.44 115.31 142.26
tya15 123.08 90.00125.09 158.01 126.15 131.40 69.57
Kaffe/jit2 103.80 130.07132.95 171.29 175.49 159.69 265.76
These were run from the cmdline with a -mx64M setting, and not from
the spec harness. Consequently, I am unable to claim that these numbers
represent Spec numbers. Let's consider them rough estimates, please.
They're nothing more. The numbers above are the averages of running
the benchmarks 2-4 times (via -m2 -M4), without regard to outliers etc.
(though there weren't any.)
The JVMs involved were:
ibmjdk: IBM JDK 1.1.8 with native threads running under RH 6.0
jdk1.2: Blackdown 1.2 with sunwjit and green threads running under RH 5.2
Kaffe/jit2: Kaffe with the old jit (the one that's in 1.0b4) under RH 5.2
Kaffe/jit3: The current Kaffe which will be released as 1.0b5 shortly.
msjvm: Microsoft 1.1 JVM running under Windows 98.
sun1.1.8: Sun's 1.1.8 JVM running under Windows 98 (uses Symantec JIT)
tya15: Blackdown JDK 1.1.7a with newest TYA jit (1.5) under RH 5.2
Everything was run on identical hardware, a dual proc PII/350.
Note the obvious caveats: we have not only different versions of JVMs
involved, but even different OSes. ibmjdk's number are particularly
inaccurate because I didn't turn off the second CPU; I saw a CPU
utilization from 100%-112% for two benchmarks, javac and mtrt, which
by the way is impressive by itself and in javac's case most likely
indicates parallel asynchronous gc. But it puts ibm's javac number
somewhat in perspective.
In addition, while I'm confident about the memory settings for the
Linux versions, I'm unsure about the settings for Microsoft's JVM.
Note that these benchmarks all generate a tremendous amount of garbage
and a JVM's performance on these benchmarks is greatly influenced by
the amount of memory available as well as the performance of its
allocator/garbage collector.
Let me repeat it again: these are ballpark numbers; any detailed
conclusions you might want to draw are inadmissible.
I should maybe add a comment about the kaffe numbers. Tim Wilkinson
wrote and integrated a faster JIT ("jit3") during this summer. This
has led to a good speedup, allowing kaffe to surpass the 1.1.7/TYA 1.5
combo for all but two benchmarks. JIT3 is available for x86, mips, m68k,
and StrongARM, it's not available for sparc and alpha at this point.
Sparc is jit2, and alpha is interpreter-only currently.
It is also interesting to note how some benchmarks are dominated by a
single aspect of a JVM. jack, for instance, throws numerous exceptions.
A JVM's jack performance is strongly influenced by the speed with which
it dispatches exceptions. Switching Kaffe's exception mechanism
to use a hashtable instead of linear search to find exception handlers, for
instance, yielded a speedup from 238 seconds to the 142 seconds.
- Godmar
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Native Threads Help
> Aaron Mulder writes: Aaron> I just installed the native threads add-on to the 1.1.7 JRE Aaron> and whenever I try to use it (jre -native test) I get the Aaron> following result: Aaron> Cannot open /proc/02891 for GCCould not create Java VM Aaron> Where the proc number changes every time... I'm using Red Aaron> Hat6.1 on a 2-processor system. Any thoughts would be Aaron> appreciated. It's a bug. Fixed in the next release. Juergen -- Juergen Kreileder, Blackdown Java-Linux Porting Team http://www.blackdown.org/java-linux.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Native Threads Help
Is there any workaround? I installed Oracle for Linux, and all it's tools run via java -native, and there are *ever so many* scripts to edit to change that! ;) Thanks, Aaron P.S. to Nathan: I have a /proc filesystem and the kernel is compiled from the Red Hat 2.2.12 source with some of the shared memory size tweaks for Oracle. On 17 Oct 1999, Juergen Kreileder wrote: > > Aaron Mulder writes: > > Aaron> I just installed the native threads add-on to the 1.1.7 JRE > Aaron> and whenever I try to use it (jre -native test) I get the > Aaron> following result: > > Aaron> Cannot open /proc/02891 for GCCould not create Java VM > > Aaron> Where the proc number changes every time... I'm using Red > Aaron> Hat6.1 on a 2-processor system. Any thoughts would be > Aaron> appreciated. > > It's a bug. Fixed in the next release. > > > Juergen > > -- > Juergen Kreileder, Blackdown Java-Linux Porting Team > http://www.blackdown.org/java-linux.html > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Native Threads Help
> Aaron Mulder writes: Aaron> Is there any workaround? I installed Oracle for Linux, and Aaron> all it's tools run via java -native, and there are *ever so Aaron> many* scripts to edit to change that! ;) You can modify jdk117_v3/bin/.java_wrapper: --- jdk117_v3/bin/.java_wrapper.bak Sun Oct 17 19:41:45 1999 +++ jdk117_v3/bin/.java_wrapper Sun Oct 17 19:41:45 1999 @@ -52,7 +52,7 @@ # if [ "$1" = "-native" -o "$1" = "-green" ]; then if [ "$1" = "-native" ]; then - THREADS_TYPE=native_threads + THREADS_TYPE=green_threads # workaround for proc bug else THREADS_TYPE=green_threads fi Aaron> P.S. to Nathan: I have a /proc filesystem and the kernel is Aaron> compiled from the Red Hat 2.2.12 source with some of the Aaron> shared memory size tweaks for Oracle. I don't remember when this bug showed up first, maybe it was with glibc-2.1.2. Aaron> On 17 Oct 1999, Juergen Kreileder wrote: >> > Aaron Mulder writes: >> Aaron> I just installed the native threads add-on to the 1.1.7 JRE Aaron> and whenever I try to use it (jre -native test) I get the Aaron> following result: >> Aaron> Cannot open /proc/02891 for GCCould not create Java VM >> Aaron> Where the proc number changes every time... I'm using Red Aaron> Hat6.1 on a 2-processor system. Any thoughts would be Aaron> appreciated. >> >> It's a bug. Fixed in the next release. Juergen -- Juergen Kreileder, Blackdown Java-Linux Porting Team http://www.blackdown.org/java-linux.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Can A Frame have a KeyListener?
Hello, The subject said it all. From my little test I would say no, but maybe there is a way for this to happen. Any solutions? TIA Wayne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Benchmark results for Linux JVMs (formatted for 70 columns)
>I ran the JVMSpec98 benchmarks from the cmdline to see how Kaffe >measures up against other JVMs. Wow, nice numbers. I'm excited to see that ibmjdk on Linux is now in the same ballpark (or faster!) as msjvm and the Sun VM on Windows. Finally, I can hold my head up with pride :-) How do other people here feel about the IBM JDK? Is it good? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
On Sun, 17 Oct 1999, Chris Abbey wrote:
> At 23:21 10/16/99 -0600, Brandon Anderson wrote:
> >
> >OK, here is the thread dump, but like I already wrote in the previous
> >post I only get this while running java_g so I don't know if its really
> >relevant.
> >
> >*** panic: "../../../../src/share/javavm/runtime/classresolver.c", line
> >1285: assertion failure
> >
> >SIGABRT 6* abort (generated by abort(3) routine)
> >stackpointer=0xbfffe370
> >
>
> ahh... now I understand better based on your previous statement:
> "I get the nasty RMI thread dump." I was assuming that you took an
> RMI related exception. (RMI is one of my fields, I was hoping it was
> something I could help with.)
>
> >
> >This continues for quite a while - atleast 2-3 pages worth of garbage. It
> >happens as soon as I try to connect to the database. This is the code
> >that it executes immediately before.
> >
> >
> > Class.forName("com.sybase.jdbc.SybDriver").newInstance();
> > String cInfo = "jdbc:sybase:Tds:server.name.com:20001";
> >
> > Connection dbConn = DriverManager.getConnection( cInfo, _props );
Sorry I meant to indicate that it dies on the very last line on the
DriverManager.getConnection( ...) statement. I think your probably right
that it is because the sybase drivers don't have debugging information
built into them, or some similar situation. Is there any way to get
around this? I don't care to actually have the sybase
instructions/functions printed. So if there is a possible way to exclude
these from being including in the debugging (Yeah, I know I'm dreaming), I
would be happy to try it.
Oh by the way, as a side question, does anyone know where I can get the
latest version of the Sybase Drivers. I'm still using jdbc 1.0 drivers
and the newer ones are suppose to have a few extra features (like batch()
commands) that would come in handy.
>
> one of those threads in that stack should be the one going through this
> code (I don't see it in the part you provided). See if you can find it and
> see what it's doing. I suspect it is on the Class.forName() call which is
> causing the class loader to blow up because sybase doesn't include
> debuggable drivers (or so I'm told . . . anyone from Sybase listening?)
> We have a similar problem at work with Oracle only providing dlls for Sun's
> VM and not IBM's. Another possibility would be that the Sybase classes load
> a native so and call a method in their static initializer that causes an
> abort signal... but I don't think this is how the classloader would respond
> to that case.
>
> >But again, this may all be unnecessary since the only thing I want to do
> >is have a working version of Runtime.trace*() functions. They don't seem
> >to do anything normally, or I just don't know how to use them properly?
>
> I suspect you do. Try this trivial test class out... if it works then you'll
> prove to your self you've got your environment setup and that you know what
> you're doing.
>
> public class test {
> public static void main(String[] args) {
>
> System.out.println("running");
>
> Runtime.getRuntime().traceMethodCalls(true);
> System.out.println("trace
> this call");
> Runtime.getRuntime().traceMethodCalls(false);
>
> System.out.println("done");
> }
> }
>
> or try using the -tm command line arg with your favorite hello world.
>
> cabbey at home dot net <*> http://members.home.net/cabbey
>I want a binary interface to the brain!
> Today's opto-mechanical digital interfaces are just too slow!
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why is Linux thread locking so slow?
Hi,
Matt Welsh wrote:
>
>
> Hi folks,
>
> I have a simple Java program where 2 threads spin in a tight loop each
> grabbing the same lock and releasing it. This is on Linux x86 and has been
> tested using GCJ 2.95.1, Blackdown JDK 1.1.7v3 (native threads), and
> IBM JDK 1.1.8 (native threads). Note that I am on an SMP system (IBM
> Netfinity Dual PIII Xeon).
>
> When the lock is uncontended, performance is fine: about 2,000 loop
> iterations per millisecond. But with more than one thread trying to
> grab the lock, performance decreases considerably: down to 25 or 30
> iters/millisecond!
>
I believe that this problem may be caused by the lack of proper support
for user-level threading in the linux kernel.
Consider what linux-threads has to go through for a contended lock:
This code is from linux-threads 0.71:
int pthread_mutex_lock(pthread_mutex_t * mutex)
{
pthread_descr self;
while(1) {
acquire(&mutex->m_spinlock);
switch(mutex->m_kind) {
case PTHREAD_MUTEX_FAST_NP:
if (mutex->m_count == 0) {
mutex->m_count = 1;
release(&mutex->m_spinlock);
return 0;
}
self = thread_self();
break;
}
CONTENDED CASE
/* Suspend ourselves, then try again */
enqueue(&mutex->m_waiting, self);
release(&mutex->m_spinlock);
suspend(self); /* This is not a cancellation point */
}
}
acquire is implemented as (while !test_and_set() __sched_yield())),
which is usually uncontended and *not* the source of the slowdown.
Now, suspend is implemented like so:
static inline void suspend(pthread_descr self)
{
sigset_t mask;
sigprocmask(SIG_SETMASK, NULL, &mask); /* Get current signal mask */
sigdelset(&mask, PTHREAD_SIG_RESTART); /* Unblock the restart signal */
do {
self->p_signal = 0;
sigsuspend(&mask); /* Wait for signal */
} while (self->p_signal != PTHREAD_SIG_RESTART);
}
In other words, every contended case implies that the two processes
exchange user-level signals. (linux-threads uses SIGUSR1/SIGUSR2.)
What kind of performance can one expect with such a scheme?
On my dual PII/350 machine, I see ca. 600 iters/ms vs. 2000 iters/ms
as reported by Matt's program.
If I limit each thread to 50 measurements, I see the following
total runtimes as reported by time:
1 thread case:
2.470u 0.000s 0:02.47 100.0%0+0k 0+0io 99pf+0w
2 thread case:
5.780u 6.540s 0:07.99 154.1%0+0k 0+0io 99pf+0w
Note the 6.5 seconds spent in system code, plus
the additional 0.8 seconds or so spent in user mode (presumably in
signal handling related code)
One thing I'm wondering about is Linux's support for SYSV-style IPC
(semop etc.). Those appear to be kernel-supported semaphores. Maybe
the problem is not in the lack of kernel support, but could be fixed
by using SysV semaphores instead? It would definitely be worth a try.
On the other hand, aren't sysv semaphores optional when you configure
your kernel? As such, there may be reason to not hardcode reliance
on them in a glibc binary distribution(?) glibc could always
test for it at run-time, though.
I believe Xavier Leroy and/or the glibc people may be the right folks
to ask. I've cc'd Xavier on this mail, maybe he has some insights
as to what whether using semop would be an option.
I should mention that this problem is also affecting the native threads
version of kaffe, where we're also seeing slowdowns for highly contended
locks.
- Godmar
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Benchmark results for Linux JVMs (formatted for 70 columns)
> > >I ran the JVMSpec98 benchmarks from the cmdline to see how Kaffe > >measures up against other JVMs. > > Wow, nice numbers. I'm excited to see that ibmjdk on Linux is now in > the same ballpark (or faster!) as msjvm and the Sun VM on Windows. > Finally, I can hold my head up with pride :-) Why? Were you involved in developing the IBM JDK? ;-) Anyway, please note the following: numbers I did not give were the numbers of Sun's current 1.2 JDK on Windows. I expect those to be faster than their 1.1 numbers on Windows. I base this guess on the assumption that most of the run-time system that's not JIT-related in Sun's 1.2 code is the same code in both Windows and Linux. As I haven't seen Sun's code, I wouldn't know whether this is true. Secondly, I haven't seen the blackdown 1.2/TYA combo. From what I grasp it's not at the point yet where it would run spec98 (?) I expect that this will perform better than the 1.1.7/TYA 1.5 combo, and possibly better than the current kaffe. If not, TYA certainly has room to grow here given the jdk1.2/sunwjit numbers. To add another reason why nobody should draw conclusions quite yet: Kaffe's benchmarks were obtained with a version of its class libraries that was compiled with jikes, which is often considered to create the slowest bytecode among the different javac compilers. - Godmar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Benchmark results for Linux JVMs (formatted for 70 columns)
>>Finally, I can hold my head up with pride :-) >Why? Were you involved in developing the IBM JDK? ;-) No, it's just that my friends who do Java on Windows can't laugh at me anymore. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why is Linux thread locking so slow?
> > One thing I'm wondering about is Linux's support for SYSV-style IPC > (semop etc.). Those appear to be kernel-supported semaphores. Maybe > the problem is not in the lack of kernel support, but could be fixed > by using SysV semaphores instead? It would definitely be worth a try. > > On the other hand, aren't sysv semaphores optional when you configure > your kernel? As such, there may be reason to not hardcode reliance > on them in a glibc binary distribution(?) glibc could always > test for it at run-time, though. > > I believe Xavier Leroy and/or the glibc people may be the right folks > to ask. I've cc'd Xavier on this mail, maybe he has some insights > as to what whether using semop would be an option. > I admit it's a long time since I used SysV semaphores. Obviously, one of the reasons why they don't see widespread application is their lack of proper reclamation when a process exits (-> ipcs, ipcrm etc.), and the lack of a mechanism to create unique keys etc., etc. FWIW, I coded Matt's example using semaphores and I'm now seeing a degradation of about 60 iters/ms vs. 600 iters/ms for the contended case. Code is at http://www.cs.utah.edu/~gback/sem-test.c if anybody is interested. Note that I've simply replaced the pthread_mutex_(un)lock() with a call to semop(); this means that we're having a system call even in the uncontended case. This is not what a sem-converted linux-thread would look like. The 600->60 comparison only makes sense if one assumes that every single attempt to lock is contended. Nevertheless, my gut feeling is that even a linux-threads that would use Linux's SysV semaphores would perform as poorly as the current signal-based implementation. So, I believe that kernel support is indeed needed. A websearch turned up an old proposal by Ulrich Drepper from 1996, in which he proposes a /proc based mechanism to implement the POSIX.1b semaphores. See http://www.uwsg.indiana.edu/hypermail/linux/kernel/9611.2/0521.html He's also suggesting ways to get around the resource reclamation and namespace problems mentioned in my first paragraph. However, it appears as though his proposal was never implemented. - Godmar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: o-protocol and it´s result: java.net.UnknownHostExceptionmailhost
> Christian Kruggel writes:
Christian> Hi there! Using Java 1.1.7B on a Linux machine and
Christian> running the appended programm leads to the following
Christian> Exception:
Christian> java.net.UnknownHostException: mailhost
Sounds like a setup problem. Can you ping mailhost? Does 'telnet
localhost smtp' work?
Christian> Really strange, because running _exactly_ the same
Christian> programm on a Sparc 5 with Sun´s JDK 1.1.8 or 1.2b just
Christian> does what it´s supposed to do: It sends an e-mail. I
Christian> attempted to explicitly change the
Christian> mailhost-system-property in the linux-environment a few
Christian> times but nothing worked, the UnknownHostException
Christian> apperas any timy I use linux. Even fiddeling arround
Christian> with the mailto-protocol itself didn´ t do anything to
Christian> the everlasting exception. Does anybody know what´s
Christian> wrong with linux or the programm?
Your code works for me.
The mailto lookup sequence is System.getProperty("mail.host"),
localhost, mailhost. In your case it looks like SendMail fails to
open a smtp connection to System.getProperty("mail.host") and to
localhost, and so it tries mailhost but the lookup fails.
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Porting Team
http://www.blackdown.org/java-linux.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can A Frame have a KeyListener?
Subclass it and declare it implements KeyListener. -- finito -- rob - Original Message - From: Wayne <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, October 16, 1999 3:50 AM Subject: Can A Frame have a KeyListener? > Hello, > The subject said it all. From my little test I would say no, but maybe > there > is a way for this to happen. Any solutions? > TIA > Wayne > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
