RE: problem jdk1.2
I ocassionally got the same thing too! Still don't know what causes it.
Most of the time a programs works fine, but suddenlly it returns this
message (probably after a did something, but I can't recall).
I thought that's my machine's problem, Now I think it might not be that
simple.
BTW, I have both jdk1.2 and MS SDK 3.1 and MS VM (latest) installed.
Any pointer??
Thanks.
Patrick.
-Original Message-
From: Ozer Irfan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 17, 1999 6:23 AM
To: Carl H. Sayres
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: problem jdk1.2
I have this message
Exception in thread "main' java.lang.NoClassDefFoundError
when I run
java test1
With javac I don't have problems
this is the program
import java.io.* ;
public class test1 {
public static void main(String args []) {
System.out.println("Hello");
}
}
Thanks
Strange timings for pre-v2 under Linux.
We have some machines running Debian 2.1 here (libc 5.4.46), and we are
running the pre-v2 Linux port of Java.
There are strange timings for the following programs. In particular, the
static version runs at about half the speed of the nonstatic version,
which seems backwards; static takes 232s and nonstatic takes 123s.
Normally, the static call should be faster to execute, since there is less
work to do. Does anyone have any ideas about why this is the case?
pat
// virtual invokes.
class myprog {
public static void main(String[] args) {
int i,j,n;
System.out.println("Beginning");
long begTime = System.currentTimeMillis();
System.out.println(begTime);
Bidule bid = new Bidule();
for (n=1; n<5000; n++) {
bid.change(1);
bid.change(2);
bid.change(3);
bid.change(4);
bid.change(5);
bid.change(6);
}
System.out.println("End");
long endTime = System.currentTimeMillis();
System.out.println(endTime);
System.out.println(" lasting : " + (endTime-begTime) );
}
}
class Bidule{
int i;
public Bidule() {
i=0;
}
public void change(int new_i) {
//System.out.println("former i : "+i+"new i : "+new_i);
i=new_i;
}
}
// myprog_static
class myprog_static {
public static void main(String[] args) {
int i,j,n;
System.out.println("Beginning");
long begTime = System.currentTimeMillis();
System.out.println(begTime);
Bidule_static bid = new Bidule_static();
for (n=1; n<5000; n++) {
Bidule_static.change(bid, 1);
Bidule_static.change(bid, 2);
Bidule_static.change(bid, 3);
Bidule_static.change(bid, 4);
Bidule_static.change(bid, 5);
Bidule_static.change(bid, 6);
}
System.out.println("End");
long endTime = System.currentTimeMillis();
System.out.println(endTime + " lasting "+ (endTime-begTime));
}
}
class Bidule_static{
int i;
public Bidule_static() {
i=0;
}
public static void change( Bidule_static bidule, int new_i) {
bidule.i=new_i;
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange timings for pre-v2 under Linux.
I forgot to mention that the machines are running the x86 JIT. Our next step is to find a way to run the Solaris versions of JDK1.2 and see what those numbers look like. pat On Fri, 2 Jul 1999, Patrick LAM wrote: > We have some machines running Debian 2.1 here (libc 5.4.46), and we are > running the pre-v2 Linux port of Java. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange timings for pre-v2 under Linux.
On Sat, 3 Jul 1999, Nick Lawson wrote: > My first guess would be that the jit is better at static calls than virtual. > Nick > > > There are strange timings for the following programs. In particular, the > > static version runs at about half the speed of the nonstatic version, > > which seems backwards; static takes 232s and nonstatic takes 123s. ^^^ (virtual) ^^^ > > Normally, the static call should be faster to execute, since there is less > > work to do. Does anyone have any ideas about why this is the case? The JIT should definitely be better at static calls. But they take twice as long. What's the deal with that? The interpreter takes about the same time for both programs. The Windows NT JIT, by the way, takes 3 seconds for the static version and 50 seconds for the nonstatic version. It probably inlines the static version, then optimizes it. pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange timings for pre-v2 under Linux.
On Sun, 4 Jul 1999, Albrecht Kleine wrote: > > I forgot to mention that the machines are running the x86 JIT. Our next > > step is to find a way to run the Solaris versions of JDK1.2 and see what > > those numbers look like. > > TYA jit 1.4 on a plain P200 jdk1.2 > takes 100 sec for myprog_static > and 110 sec for myprog. > > (But invocation is the most slow part of TYA compared w sunwjit. > This is because there's not enough knowledge about details > on invocation internals w/o using src code) Thanks. Note that Kaffe also shows a 15% speedup with static over virtual. There just seems to be a very anamolous result for the Linux JIT, where static is twice as slow. pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java-linux-digest Digest V99 #54
> I wonder how much speedup can be achieved by using tools like > Jopt ( http://www-i2.informatik.rwth-aachen.de/~markusj ). Are there any > benchmarks yet? If you keep an eye on the Sable website, by next week there will be a technical report describing how much speedup you can obtain with inlining via Soot. www.sable.mcgill.ca/publications pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Java inlining
What you've mentioned is known as method inlining. The Soot framework does this optimization on Java classfiles. (Why classfiles? See the technical report at http://www.sable.mcgill.ca/publications/sable-tr-1999-3.ps "Optimizing Java Bytecode using the Soot Framework: Is it feasible?" for a rationale and our experimental results.) Unfortunately, the version (1.beta.6) which does inlining is not yet available to the public. It does work on a vast number of Java programs. The code (under LGPL) should be online within the next two weeks. pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Some benchmark results.
I ran a few benchmarks to compare the different JVM's out there, on the SPEC benchmarks plus two of our internal benchmarks, sablecc (a parser generator), and soot, a frozen version of our analysis framework. Here are the results. These results are not scientific; in particular, I only ran each benchmark once; usually we will run them five times. So they should only be considered as an approximate measurement of the performance of the various VM's. BlackdownSun Blackdown+javacomp compress 66.01 70.45 70.75 db 146.54 112.34 153.66 jack 62.57 39.05 48.58 javac71.08 46.71 58.39 jess 48.13 33.00 36.95 mpegaudio57.95 59.27 58.59 mtrt 37.97 31.93 24.11 raytrace 51.61 30.99 32.49 sablecc-w41.92 32.16 39.11 soot-j 132.19 92.76 107.88 Blackdown denotes Blackdown JDK1.2.2RC3. Sun denotes Sun/Inprise JDK1.2.2RC1. Blackdown+javacomp is Blackdown RC3, but using the javacomp JIT provided with the Sun JDK. Tests were run on a dual-processor PII/400 running kernel 2.2.8. pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some benchmark results.
On Thu, 9 Dec 1999, Mark Christiaens wrote: > I'm not familiar with this benchmark. What is better? Higher or lower > values? Can these benchmarks also be run on a 1.1 JVM? I'm especially > interested in the IBM machine which is 1.1.8. We have results from IBM's 1.1.8 somewhere around here, and they are generally fast; I don't remember the specific numbers. The times reported were execution times, so smaller is better. I'll set up a timing run (to get more precise numbers) and include IBM's numbers at some point. pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SMP ok?
Until this question was asked, we had assumed that SMP runs fine on our dual-processor PII machines. However, come to think of it, the SPEC JVM benchmark mtrt does tend to randomly fail. We just ignored this failure, but it might indeed be due to JVM flakiness. (We don't actually write multithreaded applications here. In the past, we've tried to make our Soot java analysis framework multithreaded, but never got around to finishing it. It did initially seem to work fine, though we never tested it throughly.) pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anyone using blackdown jdk on SMP linux?
We've experienced the `java.lang.IllegalMonitorStateException: current thread not owner' exception after we run some of our test programs through Soot, our Java bytecode analysis framework. Strangely enough, the exception does not occur on the original copies of the programs, only after we Sootify. At first, I thought this was a problem with Soot, but the error seems to be the same one people are encountering without Sootifying their files. We are running Debian potato on 2.2.8 kernels, Blackdown's JDK1.2.2, with native threads, on dual-processor PII systems. pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
To optimze or not
Shameless self-promotion: The Soot framework developed at McGill University (www.sable.mcgill.ca/soot) does Java optimization. You can run your programs through Soot and they should come out a bit faster. Instructions for doing so are found at http://www.sable.mcgill.ca/soot/tutorial/optimizer/ Soot is free software (licensed under the LGPL). pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
