Chris McKillop wrote:
What version of j9?
Here is the output of “j9 --version”
Licensed Materials - Property of IBM
J9 - VM for the Java™ platform, Version 1.5
(c) Copyright IBM Corp. 1991, 2002 All Rights Reserved
Target: 20020206 (QNX 6.2.0 x86)
IBM is a registered trademark of IBM Corp.
Java and all Java-based marks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc.
Usage: j9 [options] classname [args…]
Usage: j9 [options] -jxe: [args…]
[options]
-jxe: run the named jxe file.
-jxespace:,,
map memory region for jxes, (values are in hex).
-jxeaddr:
run a jxe directly from memory, (address is in hex).
-cp: set classpath to .
-D= set the value of a system property.
-debug: start a JDWP debug server on .
-jcl:[:options]
specify which JCL DLL to use (e.g. max, xtr, …).
-verbose[:class,gc,dynload,stack,debug]
enable verbose output (default=class,gc).
-verify enable class file verification.
-X print help on non-standard options.
As I said, I don’t believe this has anything to do with j9 (io-net
has done the same), it only happens to multi-threaded apps (I have
never seen a single threaded app do this).
One thing I will say, however, is that I have disabled the
“CPU load monitor”, and so far my system seems way more
stable (although there hasn’t been enough elapsed time to be
sure yet). Is there a possibility that the CPU load monitor
de-stabilizes SMP systems ?
that strings in the QSSL supplied libstdc++ library are not
thread safe - although I googled a patch that fixes this - one
more reason to go to gcc 3.X IMO).
Yeah, and is the fact that gcc 3.x can generate bad code with -O2 a
good enough reason to not use it (very common issues on the vim lists)? > 
No. g++ v2.95 also generates bad code with -O3. I’d rather have
something that works correctly slowly than something that just
doesn’t work at all (under SMP at least). At least then I can
test my code, and know it works, as gcc improves (or as people
use different - compliant - C++ compilers), the speed of my code
improves (without having to touch my code), I am perfectly cool
with this.
I think there should be a big disclaimer on the NC download page,
that says “YOU CANNOT DEVELOP MT C++ CODE WITH THIS” and then;
“…unless you forego use of the standard library”. Right now
(without patching) you can’t even safely instantiate strings in
separate threads (that’s pretty basic functionality)…
It took years to get gcc 2 to the stable point that it is, and given that
every release of gcc v3 has claimed that “the C++ ABI is now stable”
(while breaking compt. with the last release of v3), I think v3 still needs
a little more time to cook.
I agree, until the ABI stabilizes, there is no point. As soon as the
ABI is stable, though, I think we need something that actually works
(even if only at -O0).
Besides, we provide libcpp and libecpp, which are far more compliant then GNU.
Yeah, but I’m writing software to give away, at home on NC, and I don’t
have access to these, do I ?
btw: How well has the dinkum stuff been tested on SMP ?
Rennie
,