Re: JavaOne - no green threads for Linux
Stefaan A Eeckels wrote: > > > I'm not one of the kernel folk, but can you give me an example of > an application that would be impossible without hundreds of threads? > Or even one that would significantly benefit from hundreds of threads? A RMI server on the net. One of our servers is handling now tens of connections, expected at some time to be hundreds. At this time we are using Solaris for Intel w/native threads. Even if you don't get to use all of the hundreds initially, you want your app to be scale up at least one order of magnitude at design time. -- Diego Pons Pharos Consulting LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: J2SEE 1.3 for Linux!
See below... > I have to say, I'm impressed with he power of the rumour > mill. Microsoft didn't buy out Transvirtual, they merely payed for the > development of some elements of the KaffeVM which made it compatible > with their own proprietary extensions. Despite the evil that MS > represents I have to say that they've treated Transvirtual MUCH better > than Sun. Do you mean Microsoft treated Transvirtual better than Microsoft treated Sun, or Microsoft treated Transvirtual better than Sun treated Transvirtual? (or all of the above) Just curious. Thanks -Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
idlj
After not touching Java for like a year or two, I've started a new job that is going to require some Java programming. So, I'm giving myself a refresher course in Java, using the 1.3 JDK beta. I notice it now includes idlj, which replaces the old idltojava compiler, for which, I think, there wasn't a version available for Linux. idlj is, apparently, written in Java. Anyway, the output of idlj doesn't quite grok with the CORBA tutorial (HelloWorld); namely, it doesn't generate a ImplBase abstract class but instead generates an Operations *interface*, which looks like it must be implemented for use in the derived server class. Does anyone know if this is the case? Brett W. McCoy http://www.chapelperilous.net --- Power is poison. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problems with Blackdown-Java-Plugin
Hello, I installed the recent Blackdown-Java-Plugin. I am using the Netscape 4.73 and SuSe 6.2 glibc2.1.2. There where no error or warnings during installation. NPX_PLUGIN_PATH is set to $HOME/.netscape/plugins. I can start the Java Console and it shows me, that it is using JRE-Version 1.2.2. When I start the Applet - it is a *JApplet* and packed in a jar-File - I get an error - not in the new Java Console, but in the standard-netscape-console, telling me, that javax/swing/JApplet is not found. The Java-Environment is pointing to $HOME/.netscape/java as I can see in the Java Plug-in Control Panel. I found, that the bowser still uses his own classes and not $HOME/.netscape/java/lib/rt.jar. What is the mistake? Do I have to set environment variables, such as JAVA_HOME, CLASSPATH and so on? The browser wants tu use the file "java40.jar" to start an applet. Shall I rename rt.jar? Who can help me? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JavaOne - no green threads for Linux
>> I'm not one of the kernel folk, but can you give me an example of >> an application that would be impossible without hundreds of threads? Many of these examples have a common theme - lots of network I/O to different places. We've learned from web servers that it's actually better if you multiplex your own I/O via select() rather than using fork(), but the reality is it's a big pain in the neck to write code that way. And green threads, in many ways, are just a thread abstraction on top of the select() magic that you'd have to write special purpose. >A RMI server on the net. One of our servers is handling now tens of >connections, expected at some time to be hundreds. At this time we are >using Solaris for Intel w/native threads. Sun's RMI is worse than that. It's not just one thread per other computer, it's one thread per simultaneous message. At least back in JDK 1.1, if you have two RMI calls active to another computer, you get two sockets, two threads, two everything. It gets ugly. Again, it's possible to fix this, but it's a lot of work. Wouldn't it be grand if you could just rely on the JVM to handle it for you? With green threads, you mostly could, at least up to hundreds of threads. I worry with native threads the limit is more like tens. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: idlj
Slashdot picked up my note about JavaOne. >Anyway, the output of idlj doesn't quite grok with the CORBA tutorial >(HelloWorld); namely, it doesn't generate a ImplBase abstract class >but instead generates an Operations *interface*, which looks like it >must be implemented for use in the derived server class. I haven't looked at idlj, but 1.3 does include a new dynamic proxy generation capability that means you don't have to generate Impl classes anymore, they're made on the fly. Maybe that's what's going on? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JavaOne - no green threads for Linux
[EMAIL PROTECTED] (Nelson Minar) writes: > And green threads, in many ways, are just a thread > abstraction on top of the select() magic that you'd have to write > special purpose. Still, green threads do not work very well (see the first paper on my website for details) -- and they cannot take advantage of multiple processors on an SMP. You would think that native threads are the answer but they are extremely expensive on Linux. (Solaris native threads are better but still don't scale up to thousands.) In either case we need to get Linux native threads to scale much better than they do now. This might mean convincing the kernel developers that scaling up to thousands of threads is important -- does anyone have a reading on what the kernel folks think about the current situation? In the past I believe they didn't think this was an important problem to solve. > Sun's RMI is worse than that. It's not just one thread per other > computer, it's one thread per simultaneous message. At least back in > JDK 1.1, if you have two RMI calls active to another computer, you get > two sockets, two threads, two everything. It gets ugly. I thought that Sun's RMI did fairly aggressive thread and socket sharing. NinjaRMI didn't do this because it complicated the design and made it hard to do pluggable transport layers. Matt Welsh http://www.cs.berkeley.edu/~mdw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: J2SEE 1.3 for Linux!
On Sun, Jun 11, 2000 at 08:48:13AM -0700, Larry Sanderson wrote: > > with their own proprietary extensions. Despite the evil that MS > > represents I have to say that they've treated Transvirtual MUCH better > > than Sun. > > Do you mean Microsoft treated Transvirtual better than Microsoft treated > Sun, or Microsoft treated Transvirtual better than Sun treated Transvirtual? > (or all of the above) Just curious. Ooops. Sorry for being confusing. I mean that MS has treated Transvirtual quite nicely while Sun appears to have shunned Transvirtual. --Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: idlj
On Sun, 11 Jun 2000, Nelson Minar wrote: > >Anyway, the output of idlj doesn't quite grok with the CORBA tutorial > >(HelloWorld); namely, it doesn't generate a ImplBase abstract class > >but instead generates an Operations *interface*, which looks like it > >must be implemented for use in the derived server class. > > I haven't looked at idlj, but 1.3 does include a new dynamic proxy > generation capability that means you don't have to generate Impl > classes anymore, they're made on the fly. Maybe that's what's going > on? Cool! I'll have to llok at mroe of the docs on it. Brett W. McCoy http://www.chapelperilous.net --- Be sure to evaluate the bird-hand/bush ratio. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: J2SEE 1.3 for Linux!
Christopher Smith wrote: > On Sun, Jun 11, 2000 at 08:48:13AM -0700, Larry Sanderson wrote: > > > with their own proprietary extensions. Despite the evil that MS > > > represents I have to say that they've treated Transvirtual MUCH better > > > than Sun. > > > > Do you mean Microsoft treated Transvirtual better than Microsoft treated > > Sun, or Microsoft treated Transvirtual better than Sun treated Transvirtual? > > (or all of the above) Just curious. > > Ooops. Sorry for being confusing. I mean that MS has treated > Transvirtual quite nicely while Sun appears to have shunned > Transvirtual. Interesting observation. I'm not sure I'd expect or want Sun to treat Transvirtual with anything more than benign neglect. Microsoft, for a small investment, gained the ability to claim some cross-platform capabilities for its extensions. If you're more interested in doing real work than arguing industry politics, that's a pretty nice win all around. If Transvirtual's work posed a business threat to Sun's JDK licensing or Unix platform business, I'm sure it would get much more attention from Sun - but not the sort of attention it would want. Nathan > > > --Chris > > -- > 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]
Why nonblocking I/O in Java is hard
Our discussion on thread overheads and using nonblocking I/O in Java strikes close to home - here at Berkeley we are building an event-driven Internet server platform, implemented entirely in Java. Obviously for this to work we need nonblocking I/O primitives. So, I've been working on implementing a simple nonblocking socket class in Java which lets you do nonblocking read/write/connect/accept as well as select(). It's conceptually very simple, and apart from the select() call looks just like a regular Java Socket. Turns out this is not as easy as it could be -- because even though you call system calls like read(), write(), and fcntl() from native code, these are trapped by the Java runtime library to do magic things when green threads are used! In other words, although I was creating a nonblocking socket and issuing read calls against it in JNI-based C code, those system calls (from C) were in fact being caught by the Java runtime library which was turning them back into "blocking" access to the socket. This is because the green threads library is very aggressive about preventing native code from stalling the whole application by issuing a blocking system call - it in fact turns all blocking system calls into nonblocking calls, and issues (green thread) context switches when a block would occur. The solution? Go behind JNI's back, and get the "real" system call handles by using dlopen/dlsym on /lib/libc.so.6 (or wherever your standard C library happens to be installed), and call them directly. The good news is that it seems to work. Note that when native threads are used, the JDK does not attempt any funny business, and there are no problems. Matt Welsh, UC Berkeley -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
jdk1.3 for linux?
I want to download jdk1.3 for linux,but http://java.sun.com/jdc/earlyAccess/j2sdk13/download-linux.html can't be linked. Anyone knows where is the suitale downloaded site.
Re: Why nonblocking I/O in Java is hard
Matt Welsh wrote: In other words, although I was creating a nonblocking socket and issuing read calls against it in JNI-based C code, those system calls (from C) were in fact being caught by the Java runtime library which was turning them back into "blocking" access to the socket. This is because the green threads library is very aggressive about preventing native code from stalling the whole application by issuing a blocking system call - it in fact turns all blocking system calls into nonblocking calls, and issues (green thread) context switches when a block would occur. The solution? Go behind JNI's back, and get the "real" system call handles by using dlopen/dlsym on /lib/libc.so.6 (or wherever your standard C library happens to be installed), and call them directly. Isn't that a bit dangerous? It sounds like looking for trouble with the green-threads lib by mixing it with direct access to the system libs. It should be really nasty to debug, in the very likely case of unexpected behavior... (apart from that, it's a very cool hack though ;-) The good news is that it seems to work. Note that when native threads are used, the JDK does not attempt any funny business, and there are no problems. Since the thread proliferation problem really affects only native threads vm, why don't you fall back to thread-based i/o on detecting green threads (where you can simulate non-blocking i/o by creating the usual mess of buffers and i/o devoted threads)? I know that it's a mess, but I would expect to get more predictable behavior in this way. -- dimitris mailto:[EMAIL PROTECTED]
Re: jdk1.3 for linux?
On Mon, 12 Jun 2000, wangmq wrote: > I want to download jdk1.3 for linux,but > http://java.sun.com/jdc/earlyAccess/j2sdk13/download-linux.html can't > be linked. Anyone knows where is the suitale downloaded site. Try: http://developer.java.sun.com/developer/earlyAccess/j2sdk13/download-linux.html That's where I got it from. Brett W. McCoy http://www.chapelperilous.net --- "If Diet Coke did not exist it would have been neccessary to invent it." -- Karl Lehenbauer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: visual age and jdk1.3
On Sun, Jun 11, 2000 at 11:54:13AM +0800, yangyuexiang wrote: > I installed jdk1.3 from IBM in my redhat 6.2. Today, I > installed VisualAge 3.0, when I run the software, following > error occurred. > ... > 1) Primitive failed in: PlatformFunction>>#callWith:with:with:with:with:with: due to >General > protection fault I faced the same problem. It seems that you have to run this product as root, if "root" was the one who installed it. I haven't tried installing it as a normal user and then using it. -- Mojahed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
jdk1.3/forte problem
I tried running the recent jdk1.3+hotspot downloaded from sun with forte community edition 1.0 v502. It has a problem whereby the jmenus pull down but then immediately disappear, so it is impossible to select any menu items. Any thoughts or suggestions on what to try? / thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
More on idlj
Now I feel rather foolish about my earlier question on idlj: the _Impl classes weren't generated because I didn't use the -fserver argument to the compiler. Doh! But all is well now... Brett W. McCoy http://www.chapelperilous.net --- The rule on staying alive as a forecaster is to give 'em a number or give 'em a date, but never give 'em both at once. -- Jane Bryant Quinn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why nonblocking I/O in Java is hard
Dimitris Vyzovitis <[EMAIL PROTECTED]> writes: > > Isn't that a bit dangerous? Well - anything you do with native code in Java is inherently "dangerous". Obviously it's best to use native threads when doing this kind of thing, but I want compatibility with green threads in case people need that. > Since the thread proliferation problem really affects only native threads > vm, That's not quite true - there is still a limitation on creating a large number of green threads to simulate nonblocking I/O. Although green threads effectively use select() and nonblocking I/O internally, they don't seem to scale -- exactly why, I don't know -- probably because of things like scheduler overhead. Matt Welsh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
java Script
Now i have a problem about javaScript. I want to abtain client browser width with javaScript, who has a good idea?
