Re: Image/Thread Problems
Nathan Meyers wrote: > I've been doing some work with java.awt.Images in the past few days > (1.2pre2 for glibc2.0, native threads, RH5.2), and I seem to be hitting > some strange deadlocks between my event and image-loading threads. As > best I can tell, it looks like ImageObserver.imageUpdate() is not being > reliably called while I'm waiting for an image to load. > > I've been reading about these elusive threading problems delaying the > 1.2 release... have they been known to assert themselves when dealing > with Images? (The real question for me: do I stare at my code and > scratch my head, or might I be able to blame the JVM or maybe the image > classlibs?) > I found exactly this problem is Sun's Windows JDK 1.2, so its probably something in the class libsm although I haven't investigated further. Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Image/Thread Problems
Nathan Meyers wrote: > Nick Lawson wrote: > > > > Nathan Meyers wrote: > > > > > I've been doing some work with java.awt.Images in the past few days > > > (1.2pre2 for glibc2.0, native threads, RH5.2), and I seem to be hitting > > > some strange deadlocks between my event and image-loading threads. As > > > best I can tell, it looks like ImageObserver.imageUpdate() is not being > > > reliably called while I'm waiting for an image to load. > > > > I found exactly this problem is Sun's Windows JDK 1.2, so its probably something > > in the class libsm although I haven't investigated further. > > Thanks! I recall encountering references in the Sun bug parade to > problems with those class libs, and your observation strengthens the > case. P.S. I only encountered this problem whwn loading several images simultaneously. I bypassed it by loading them sequentially instead - not at all painful if the images are local. Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange timings for pre-v2 under Linux.
My first guess would be that the jit is better at static calls than virtual.
Nick
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.
>
> 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]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Java Servlets: getting started on Linux]
Hi, The servlet development kit is not in Suns JDK 2 - you have to download it separately. To have java & javac, etc. pick it up, copy servlet.jar to jdk/jre/lib/ext/ If you want to use the demo httpserver, also copy the server.jar to this directory. See jdk/docs/guide/extensions/index.html for the extension mechanism in general. Nick > > Pat Trainor <[EMAIL PROTECTED]> wrote: > > Now I'm very, very new to Java, but have purchased 14 books, > including "Java Servlet Programming" by John Hunter. As I see it, adding > servlet compatibility to a .java source is simply placing the jsdk.jar in > the CLASSPATH, right? Documentation says that javac compiles servlets, > applets, scriptlets no sweat. I have no fancy Borland or MS tools. > > But other documentation says it is included in the JDK v2.0 > ..problem is that using imports for those classes/packages does not find > the javax.* stuff! On linux I'm hoping to have more success, and it is > also my development platform of choice for Perl and DBI/ODBC. > > Additionally, there are many versions of the JDK, apparently, > including GNU style. Which works with what? When is JRE necessary? I hope > someone else has been through this rite of passage before me! > > As an aside, has anyone any experience with Netscape Enterprise > v3? I read that it only supports Servlet API v1.0, and is considered > unstable. I may HAVE to develop on this platform, and would really like to > hear what to do, or not, in order to use this platform on Sun Ultra. > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Has Sun Overstretch Themselves With So Many APIs?
Not only is Visual J++ not Java, the Java VM delivered with Internet Explorer is not java - MS has removed rmi and Corba. Nick Larry Gates wrote: > >Date: Fri, 09 Jul 1999 07:02:02 -0400 > >From: "Thomas M. Sasala" <[EMAIL PROTECTED]> > > > Perhaps it takes a large API to reproduce something Apple, Microsloth, > >Sun, HP, etc. have been working on for 20 years. > > > > FWIW, I don't think the API has anything to do with write once, > >run noum, any where. Clearly Microsoft has been able to turn > >Java in to a platform specific language with little help. > > 2 things: > > Hey, I thought the consensus was that Visual J++ was NOT Java, even > though Microsquash was calling it Java. Which in turn, prompted one > of many suites filed by Sun? Did I get this right? Anyone know how > the lawsuit is coming along? > > I think we all hope that someday "write once, run anywhere" will be a > true statement about Java. > > -Larry Gates > > > -T > > > >jools enticknap wrote: > >> > >> >I am wondering if Sun has overstretch itself in trying to develop so > >> >many APIs? It seems to me that they are struggling and there is enough > >> >support and help to help outsiders (like Blackdown who done an excellent > >> >job porting the software)? > >> > >> > >> > >> Perhaps this is a direct result of trying to bring an open technology to > >> market, and at the same time protect the one thing that makes Java useful in > >> the first place (write once, run everywhere(TM)). > >> > >> Also once a technology is invented it needs time for the comunity to > >> evaluate and comment on whats been done, and these comments must also be > >> evaluted and the next step then taken. > >> > >> This all takes time, however I for one and happy this does take place. > >> > >> As for porting assistance, I think that you will find that SUN has __very__ > >> close links with the blackdown guys and do offer help when it's requested. > > -- > 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: Has Sun Overstretch Themselves With So Many APIs?
I'd have to go along with Brad on this, after using the Swing text API. I ended up having to subclass lots of stuff, while reading the java sources to find out what the superclasses were up to. Nick Brad Pepers wrote: > Rachit Siamwalla wrote: > > > > > Agreed, Swing JFC is one of the best API design ever. Java 2D/ DnD is excellent > > > and JMF appears to be well though out. I await Java Sound with baited breath. > > > > > > > I don't 100% agree with the comment about JFC. Some things in JFC are > > well written like the JTree and the JTable and the Text components. But > > the rest seem slapped together and hard to customize without creating > > your own components. Another thing is it is scary how slow they seem to > > fix problems. I heard from someone who went to JavaOne last year that > > they have 10 people devoted to Swing. How long has JFC came out? A lot > > of repeatable problems have not been fixed. This is amazingly bad. What > > have they been doing? The interface hasn't changed significantly. All > > there is to do is fix thier bugs. Oh well... > > I can't even go that far since JTable has its own problems. Like you > mentioned its hard to customize without creating your own component and > its also almost useless for data entry. In general the whole thing is > missing so much basical functionality that you end up spending all your > time subclassing their components. Little things like the simplest of > data validation (limiting the number of characters entered for instance) > require you to write code when it should be basic functionality of the > component. > > I think they've had to spend *way* too much time on getting the whole > switchable look and feel working and in doing so have left out basic > functionality. Its also so complicated its hard to subclass and get > control of the behaviour when you need to (and I also suspect this is > the source of the bugs and why they can't fix them). They should have > just worked on a light weight set of components with a rich set of > functionality and a nice look and feel. AWT is bad because it relies > on the underlying graphics lib which creates subtle differences in > functionality between operating systems but JFC seems to be just as bad > by trying to cater to everyone they have made a system not very good > for anyone. > > If its not obvious, I've been working with Swing for a while now and had > nothing but frustration. 8^) > > Rant mode off. > > Are there other options out there? > > -- > Brad Pepers > Linux Canada Inc.Home of Linux products in Canada! > http://www.linuxcanada.com Proud supporter of Cyclades, Red > [EMAIL PROTECTED] Hat, and Caldera. > > -- > 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: java.lang.OutOfMemoryError
In JDK 1.2 the default max heap size is 16 Mb - I can't remember what
it was in 1.1. Is this your problem ? You can specify a larger heap
with the command line option -Xmx32m, for example.
Nick
Luigi Giuri wrote:
> I'm having a problem using jdk117_v1a + Apache-JServ-1.0b3.
>
> The problem is that sometimes a java.lang.OutOfMemoryError occurs,
> so I need to restart the JVM.
>
> To test the jdk, I wrote the following simple program:
>
> import java.util.*;
>
> public class crashMe
> {
> public static void main(String [] argv)
> throws Throwable
> {
> try
> {
> Vector v = new Vector();
>
> int i = 0;
> while (true)
> {
> v.addElement(
> new StringBuffer(1));
> System.out.println(++i);
> }
> } catch (Throwable e) {
> System.out.println("Exception!!! Press to continue...");
> System.in.read();
> throw e;
> }
> }
> }
>
> The objective of this program is to fill the computer RAM and swap area but,
> suddendly, when it crashes with a java.lang.OutOfMemoryError there are
> 66000 KB of free RAM (on a 96MB computer).
>
> I tried the jdk117_v3, but I obtained the same result.
> I also turned off the JIT compiler.
>
> Here is the command line:
>
> $ /usr/local/jdk117_v3/bin/java -classpath
> .:/usr/local/jdk117_v3/lib/classes.zip -Djava.compiler=NONE crashMe
>
> In my computer the above program crashes at iteration n. 525.
> If I allocate StringBuffer(100) (one million) it crashes after
> four iterations.
>
> What's the problem?
>
> Luigi Giuri
>
> --
> 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: java.lang.OutOfMemoryError
Sorry about the syntax error: the options are different in different JDKs; -Xmx32m is correct for Suns JDK 1.2. Nick Luigi Giuri wrote: > At 11.21 12/07/99 +0100, Nick Lawson wrote: > >In JDK 1.2 the default max heap size is 16 Mb - I can't remember what > >it was in 1.1. Is this your problem ? > > Yes !!! > > >You can specify a larger heap > >with the command line option -Xmx32m, for example. > > Right, there is only a little syntax error: the option is -mx32m. > > Thank you very much. > > Luigi > > -- > 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: Has Sun Overstretch Themselves With So Many APIs?
Fair comment. I was one of those who had a moan about Swing in this thread, but I still think Java is the best development tool I have ever seen. I guess we all got used to this luxury already! Nick Rudi Streif wrote: > Pretty interesting discussion. Basically you are talking about the dilemma > everyone has to face if he wants to develop a framework that is meant to be > used by others. If he makes it too generic then there will be a bunch of > people who complain that it is hard to use, that the turnaround times are > too long etc. If he makes it too specific then there will be lots of people > who complain that it doesn't fit their needs, that they cannot adjust it > etc. So what to do? > > In my opinion Sun did and still does a very good job with the whole Java > API, not only the Swing toolkit. They provide all the necessary features > usually missing in other toolkits but still leave it flexible enough to make > your own changes. And they also leave enough room for third party suppliers > who then can provide more specific add-ons to the API that may be easier to > use. I agree, the Java API is not easy to use. It implements all the aspects > of object-oriented analysis and design. It utilizes object patterns like > factories, iterators, singletons etc. Understanding all these concepts > really helps you to get most out of the JAVA API. > > Sun's developers are really knowledgeable people. They turned theoretic and > abstract concepts discussed by system analysis and software experts for > years now into a highly usable real world product. If have been searching > for something like this for years. Finally I have found it. And the best > thing: it's for free. > > Rudy > > -Original Message- > From: Brad Pepers <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Date: Saturday, July 10, 1999 12:47 AM > Subject: Re: Has Sun Overstretch Themselves With So Many APIs? > > >Rachit Siamwalla wrote: > >> > >> > Agreed, Swing JFC is one of the best API design ever. Java 2D/ DnD is > excellent > >> > and JMF appears to be well though out. I await Java Sound with baited > breath. > >> > > >> > >> I don't 100% agree with the comment about JFC. Some things in JFC are > >> well written like the JTree and the JTable and the Text components. But > >> the rest seem slapped together and hard to customize without creating > >> your own components. Another thing is it is scary how slow they seem to > >> fix problems. I heard from someone who went to JavaOne last year that > >> they have 10 people devoted to Swing. How long has JFC came out? A lot > >> of repeatable problems have not been fixed. This is amazingly bad. What > >> have they been doing? The interface hasn't changed significantly. All > >> there is to do is fix thier bugs. Oh well... > > > >I can't even go that far since JTable has its own problems. Like you > >mentioned its hard to customize without creating your own component and > >its also almost useless for data entry. In general the whole thing is > >missing so much basical functionality that you end up spending all your > >time subclassing their components. Little things like the simplest of > >data validation (limiting the number of characters entered for instance) > >require you to write code when it should be basic functionality of the > >component. > > > >I think they've had to spend *way* too much time on getting the whole > >switchable look and feel working and in doing so have left out basic > >functionality. Its also so complicated its hard to subclass and get > >control of the behaviour when you need to (and I also suspect this is > >the source of the bugs and why they can't fix them). They should have > >just worked on a light weight set of components with a rich set of > >functionality and a nice look and feel. AWT is bad because it relies > >on the underlying graphics lib which creates subtle differences in > >functionality between operating systems but JFC seems to be just as bad > >by trying to cater to everyone they have made a system not very good > >for anyone. > > > >If its not obvious, I've been working with Swing for a while now and had > >nothing but frustration. 8^) > > > >Rant mode off. > > > >Are there other options out there? > > > >-- > >Brad Pepers > >Linux Canada Inc.Home of Linux products in Canada! > >http://www.linuxcanada.com Proud supporter of Cyclades, Red > >[EMAIL PROTECTED] Hat, and Caldera. > > > > > >-- > >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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject o
Re: java.lang.OutOfMemoryError
Hi Crispin, How you doing?
Your original question never did get a satisfactory answer.
However it's definitely not the same as Luigi's.
Perhaps you could try the code below; on Suns Windows JDK1.2
the total
stays constant at 1m, and the free highwater mark hovers
around 820k,
at least for the first 4 million iterations round the inner
loop.
My linux died, so I can't try it here (
Nick
public class SBTest2 {
public static void main( String[] args ) {
int i = 0;
while(true) {
long free = Runtime.getRuntime().freeMemory();
long total = Runtime.getRuntime().totalMemory();
for( int j = 0; j < 1000; j++ ) {
System.out.println(i + ", free = " + free + ",
total = " + total );
i++;
}
}
}
}
Crispin Miller wrote:
> I posted to the group recently with a very similar problem to Luigi's problem -
> I think there is a memory leak in StringBuffer somewhere: the following code
> slowly eats up memory (it doesn't on a Sun).
>
> (running on JDK1.2-pre1).
>
> import java.util.*;
>
> public class SBTest {
> public SBTest() {
>int i = 0;
>while(true) {
> System.out.println(i + " ");
>i++;
>System.out.flush();
>System.gc();
>}
> }
>
> public static void main(String[] args) {
>SBTest m = new SBTest();
>
> }
> }
>
> Crispin
>
> --
> 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: Stupid question
Depends which Java you have. Its probably Kaffe if you installed from a redhat RPM. In that case it will be JDK 1.1, and you will need to set the classpath to point at the class library. If you can't find any documentation, you could always download the tools documentation from Suns web site José David MartÃnez Cuevas wrote: > Hi. > Since i heard about Java, i wanted to learn the language... > Now I finally had the oportunity, but into a Linux Box !! > > But i'm having some problems with it... > when i try to compile a program with the 'javac' > i got the next message: > > "Unable to initialize threads: cannot find class: java/lang/Thread" > > What should i do ??? > > Thanks !! > > PS: I installed from a RPM, i'm using Red Hat 5.2 > > -- > 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: java.lang.OutOfMemoryError
You say you get a stack overflow ? is that stack overflow as in java.lang.StackOverflowError ? That sounds impossible !! This error is supposed to mean too many nested method calls, but your program doesn't do any nested calls ! If this is what is happening, send me the class file and I'll decompile to see what the byte-code is doing. Nick > i) Watching it using 'top', the process slowly grows in size... > ii) After about 550,000 iterations the program dies with a stack overflow error... > > Crispin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux-Bug with ?
This sounds like a HUGE bug ! Is it just in the Blackdown JDK 1.2, or also in Suns JDK ? Is there a fix ? Are there others like this ? Where is a good place to look for such hi-impact bugs ? Nick Juergen Kreileder wrote: > > Oktay Akbal writes: > > Oktay> I think there is a Bug in the implementation of the conditional > Oktay> (ternary) operator in the latest jdk1.2 for linux. > > It's a known bug in the JIT compiler (sunwjit). Turn the JIT off and > it will work. > > 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: final variables in constructors (OT)
The java language specification is a little difficult to follow on final static
fields.
The best place to look is 13.4.8 - Binary Compatability. This says
"We call a field that is static, final, and initialized with a compile-time
constant expression a primitive constant."
and it is implicit in the following discussion that such values are always
inlined.
So these are exactly the constants that Kontorotsui is looking for, and as Chris
says there is a bug in the compiler - but not in Suns compiler, which is quite
happy with
the example.
BTW, the variable v doesn't need to be final in this particular example,
and the spec. recommends that it should not be, for binary compatibility reasons.
But if you want the constant behaviour of final then probably "private static
final"
is the best solution. If such constants are put in a separate class as Chris
suggests
then if the value is changed you have to be careful to recompile EVERY class that
references them.
Nick
Chris Abbey wrote:
> At 11:05 AM 7/16/99 +0200, Kontorotsui wrote:
> >
> >On 14-Jul-99 Michael Sinz wrote:
> >> The reason is that until the constructor is called, no instance data
> >> can be used. Note that you did not make this static final but rather
> >> final. This means there must be actual instance data to access this
> >> variable and that does not exist until super() returns since until
> >> that point in time *no* instance data space was allocated (let alone
> >> initialized)
> >
> >Ok, but it doesn't work either with static final.
>
> Then there is a bug in javac... http://java.sun.com/cgi-bin/bugreport.cgi
>
> Jikes will accept the following code:
> class aSuperClass {
> aSuperClass(int i) {
> System.out.println("aSupperClass("+i+")");
> }
> }
> class aClass extends aSuperClass {
> static final int v = 1;
> aClass() {
> super(v);
> System.out.println("aClass()");
> }
> }
> class mainline {
> public static void main(String[] a) {
> new aClass();
> }
> }
>
> and the result of a run is:
> aSupperClass(1)
> aClass()
>
> >> Actually, unless it is statis final it is not a real constant.
> >> And even static final is a variable, it just happens to be unchangeable.
> >
> >Ok, then what is missing is a real constant in Java, something useful only
> for
> >the code writer and that can be automatically substituted by the
> preprocessor.
>
> Actually with the way class files are designed there either really is no
> such thing, or everything is like that. (it depends on your POV.) I tend
> to view it as "static final is #DEFINE" when it comes to primitives; objects
> are different! For example, the aClass above disassembles into :
>
> Method aClass()
>0 aload_0
>1 iconst_1
>2 invokespecial #15
>5 getstatic #21
>8 ldc #23
> 10 invokevirtual #29
> 13 return
>
> iconst_1 is a bytecode special item because numbers like 0 and 1 occur SO
> often in code that they have special bytecode representation; there is one
> for each of -1..5. If I make that 1024 instead...
>
> Method aClass()
>0 aload_0
>1 sipush 1024
>4 invokespecial #15
>7 getstatic #21
> 10 ldc #23
> 12 invokevirtual #29
> 15 return
>
> As you can see the value 1024 is "hard coded" into the bytecode just like
> you want.
>
> [...]
> >As you see the lack of a real constant forces me to manually put 15 in the
> >constructor and in the for upper bound. This is bad because if one day I want
> >the 15 to be a 18, I'll have to remember to change it also in the for.
>
> Make it "static final int MYCONST=18;" and get a better compiler.
>
> Another option is to put it in another class... for example a project I
> work on has a class CONST in each package which is final and contains
> nothing but static finals fields; then you code super(CONST.someproperty);
> In theory these are all package wide constants... and there are similar
> classes in all packages, including superpackages.
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JIT instability w.r.t. bad code?
I'm pretty sure try{}catch{} catch blocks add NO overhead to code,
unless the exception actually gets thrown. But exceptions are
supposed to be
exceptional, so who cares how slow it is ?
Check out how exception handling is implemented in Java byte-code
in the Java Virtual Machine Specification, 4.7.3 - The Code
Attribute.
Nick
Rachit Siamwalla wrote:
> This is funny, because a while ago (quite a while), people said that
> this code:
>
> if (intArray == null)
> return intArray[3];
> else
> return -1;
>
> was slower than this code:
>
> try{
> return intArray[3];
> }
> catch (NullPointerException e)
> {
> return -1
> }
>
> precisely because the JVM does the check for you anyway and the check
> will be done twice (unless you have a JIT), especially if the condition
> doesn't happen too often (there is still an overhead of generating the
> exception -- which is quite large).
>
> I guess times have changed :)
>
> -rchit
>
> Jim Kimball wrote:
> >
> > It was my understanding that code wrapped in an exception handler
> > introduces more overhead to the JVM. I am sure I have seen articles on
> > this exact topic in Java World or Java Report.
> >
> > Jim
> >
> > Dimitris Vyzovitis wrote:
> > >
> > > SHUDO Kazuyuki wrote:
> > >
> > > > > Personally I prefer explicit checks.
> > > >
> > > > Why?
> > > >
> > >
> > > I am also tempted to ask why
> > > Is there any particular reason to add client side check for what the VM does on
> > > its own?
> > > I personally think that there is no need to do explicit checks in your code
> > > (it is inherently suboptimal) and let the VM do its work - just add the
> > > required exception handlers ;-}.
> > >
> > > -- dimitris
> > >
(Apologies to jim for sending you this twice).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JIT instability w.r.t. bad code?
Nathan Meyers wrote:
> Nick Lawson wrote:
> >
> > I'm pretty sure try{}catch{} catch blocks add NO overhead to code,
> > unless the exception actually gets thrown. But exceptions are
> > supposed to be
> > exceptional, so who cares how slow it is ?
> >
>
> Times for attached program (JDK1.2pre2, glibc2.1, RH6, 200MHZ PPro,
> 5 iterations):
>
> No JIT sunwjit tya
> -- --- ---
> With try/catch 278793 17925 33894
> Without 237905 15364 35803
>
> %slower 17.2% 16.7% -5.3%
>
> I'd be surprised to see a zero-overhead try/catch, although tya seems to
> be on to something :-).
>
> Results are unaffected by -O compilation.
>
> Nathan
Ok, NO overhead for try..catch is an exaggeration. But only a small one
- typically there is exactly one extra bytecode instruction per try,
to branch round the catch{} clauses. Most C++ compilers produce similar
code,
and it would be easy for an optimizing java compiler to produce code
without even this overhead (although I haven't seen one that does so yet).
The byte-code produced by jdk1.2pre-v2 for the Hello program is reproduced
below.
Suns JDK 1.2 produces exactly the same code (of course!).
The extra instructions for the try..catch are marked with a !
Theres just 3 of them, and only one gets executed if the exception is not
thrown.
I guess the question was whether try..catch is faster or slower
than the alternatives. I think the program below is more
like the sort of situation that occurs in real life.
The times for this (Pentium 166, Sun Windows 95 JDK 1.2, Blackdown 1.2pre-v2
+ glibc 2.1 + OpenLinux 2.2,
500,000,000 iterations):
VM: kaffeSunSunBlackdownBlackdown
JIT: symcjitnone sunwjitnone
---- ---
With try/catch388,21212,360545,410136,207466,300
Without 396,40115,490601,000143,784508,770
%faster2%20% 9.2% 5.2% 8.3%
- the last column is estimated from 50,000,000 iterations.
I didn't believe the Sun VM figures either, but I tried both tests
several times, and the figures are consistent, scale linearly with
the number of iterations, and match wall-clock time. So it looks
like symcjit is pretty smart !
Nick
-
import java.util.*;
public class Hello2 {
public static void main(String[] argv) throws Exception {
int count = Integer.parseInt(argv[0]);
Boolean foobar = new Boolean(false);
Date date1 = new Date();
for (int i = 0; i < count;) {
try {
if (!foobar.booleanValue()) i++;
}
catch (Exception e) {
System.err.println( "Oops!" );
}
}
Date date2 = new Date();
Date date3 = new Date();
for (int i = 0; i < count;) {
if(foobar != null) {
if (!foobar.booleanValue()) i++;
}
else {
System.err.println( "Oops!" );
}
}
Date date4 = new Date();
System.out.println("First loop (try): " +
(date2.getTime() - date1.getTime()));
System.out.println("Second loop (no try): " +
(date4.getTime() - date3.getTime()));
}
}
-
Bytecode from Nathans Hello.java:
Code Disassembly:
Addr Op Operands Code
--
...
...
0011 03 iconst_0// for( int i = 0; .
0012 36 04 istore L4 // (store i)
0014 a7 001b goto +1b = 002f
try #1
0017 84 0401 iinc L4,1 // { i++;
001a 1d iload_3
001b 99 000b ifeq +b = 0026 // if( foobar ) ...
001e bb 0005 new #5
0021 59 dup
0022 b7 000b invokespecial #11 ()>
0025 bf athrow // throw ...
0026 1d iload_3 // foobar = foobar &&
true;
0027 3e istore_3
end try #1
! 0028 a7 0007 goto +7 = 002f // branch around catch
catch #1 (Exception)
! 002b 57 pop // start catch clause
! 002c a7 0003 goto +3 = 002f // end catch clause
002f 15 04 iload L4// }
0031 1b iload_1
0032 a1 ffe5 if_icmplt -1b = 0017// end for loop 1
...
...
0047 03 iconst_0 // for( int i = 0; .
0048 36 07 istore L7 //
Re: JIT instability w.r.t. bad code?
I have a (Java) program that does this, although I added the comments
by hand.
Writing a decompiler seemed like a good way to learn jvm. I didn't
originally intend to decompile byte codes, by as usual I got carried away
Nick
Chris Abbey wrote:
> Nick, what program did you use to generate the listing? or did you build
> it by hand from javap output? -=Chris
>
> At 03:17 PM 7/18/99 +0100, you wrote:
> [...]
> >-
> >Bytecode from Nathans Hello.java:
> >Code Disassembly:
> >
> > Addr Op Operands Code
> > --
> >
> >...
> >...
> > 0011 03 iconst_0// for( int i = 0; .
> > 0012 36 04 istore L4 // (store i)
> > 0014 a7 001b goto +1b = 002f
> >try #1
> > 0017 84 0401 iinc L4,1 // { i++;
> > 001a 1d iload_3
> > 001b 99 000b ifeq +b = 0026 // if( foobar ) ...
> > 001e bb 0005 new #5
> > 0021 59 dup
> > 0022 b7 000b invokespecial #11 ()>
> > 0025 bf athrow // throw ...
> > 0026 1d iload_3 // foobar = foobar &&
> >true;
> > 0027 3e istore_3
> >end try #1
> >! 0028 a7 0007 goto +7 = 002f // branch around catch
> >catch #1 (Exception)
> >! 002b 57 pop // start catch clause
> >! 002c a7 0003 goto +3 = 002f // end catch clause
> > 002f 15 04 iload L4// }
> > 0031 1b iload_1
> > 0032 a1 ffe5 if_icmplt -1b = 0017// end for loop 1
> >...
> >...
> > 0047 03 iconst_0 // for( int i = 0; .
> > 0048 36 07 istore L7 // (store i)
> > 004a a7 0014 goto +14 = 005e
> > 004d 84 0701 iinc L7,1 // { i++;
> > 0050 1d iload_3
> > 0051 99 000b ifeq +b = 005c // if( foobar ) ...
> > 0054 bb 0005 new #5
> > 0057 59 dup
> > 0058 b7 000b invokespecial #11 ()>
> > 005b bf athrow // throw ...
> > 005c 1d iload_3
> > 005d 3e istore_3 // foobar = foobar &&
> >true;
> > 005e 15 07 iload L7 // }
> > 0060 1b iload_1
> > 0061 a1 ffec if_icmplt -14 = 004d // end for loop 2
> >...
>
> 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]
Re: JIT instability w.r.t. bad code?
Nathan Meyers wrote: > Nick Lawson wrote: > > > > Pretty impressive optimization on symcjit, though it smells a bit like a > compiler that's been tuned to the benchmarks. Does it perform that well > on real applications? > > Nathan > I can only comment on one real application - matrix diagonalization, which is heavy floating point stuff. One method, theres no real difference between sunwjit and symcjit, a second method symcjit is about 3 times faster. These methods are copied from Numerical Algorithms in C, so maybe your point about benchmarks could still apply . although I had to de-optimize the C code in order to understand it ! Nick > > > The times for this (Pentium 166, Sun Windows 95 JDK 1.2, Blackdown 1.2pre-v2 > > + glibc 2.1 + OpenLinux 2.2, > > 500,000,000 iterations): > > > > VM: kaffeSunSunBlackdownBlackdown > > JIT: symcjitnone sunwjitnone > > ---- --- > > With try/catch388,21212,360545,410136,207466,300 > > Without 396,40115,490601,000143,784508,770 > > > > %faster2%20% 9.2% 5.2% 8.3% > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
