JDK & native threads
I'm starting to pull out my hair from the fact that the current JDK is based on user threads. I can't call anything that can potentially block, because everything will block. An alternative is Kaffe, but it's too incomplete to be usable right now. Is anyone working on producing a version of the JDK that uses native threads ? I remember reading about some "problems" with this. What are the problems ? Thanks.
Re: JDK & native threads
Gerald Gutierrez <[EMAIL PROTECTED]> writes: > I'm starting to pull out my hair from the fact that the current JDK is > based on user threads. I can't call anything that can potentially block, > because everything will block. "Green threads" converts all your blocking I/O into non-blocking ones by providing wrappers around read/open etc. You should not be able to write a Java program that starves/blocks all other threads[1]; if you can, then it there is a bug in the green threads implemenation. In general, yes, green threads are a pain in the behind. > An alternative is Kaffe, but it's too incomplete to be usable right now. > Is anyone working on producing a version of the JDK that uses native > threads ? I played with the JDK sources, and noticed that it is possible to port JDK to run on Xavier Leroy's LinuxThreads. A casual hack is one thing, but a product version is another. Didn't Open Group announce a native threads port of 1.1.6 on this list? I've lost the URL. > I remember reading about some "problems" with this. What are the problems? The basic problem is that POSIX threads (the API implemented by LinuxThreads) doesn't have suspend and resume primitives. These are required because: - Of the need to support the java.lang.Thread.suspend() and resume() methods (these 2 have been deprecated in 1.2). - Sun's implementation starting a new thread suspended. - You need to suspend other threads during garbage collection. Note to friends of LinuxThreads: LinuxThreads FAQ indicates that one workaround is to post SIGSTOP and SIGCONT signals and these are akin to suspend/resume. However, I noticed that if a process flags has PF_PTRACED, the SIGSTOP isn't really delivered, meaning I can't run the VM under gdb -- which makes this option useless. I'll have to find an alternative solution for suspend/resume. LinuxThreads uses SIGUSR1 and SIGUSR2, so it is not so embeddable. Don't get me wrong -- I like LinuxThreads, I was impressed by the cleanliness of its implementation, and it just works, but threads the kernel really understood would be nice. -Anand [1] Two caveats: - compute bound threads can starve other threads. But there is a un-supported -ts flag that makes the green threads VM time slice. - native methods can short-circuit the wrappers and block. Native methods in the JDK don't do this. Also System.in.read() is known to block the entire process on Solaris green threads atleast (fixed in 1.2).
JDK1.1.6v4 for i386
hi, i tried looking for the JDK1.1.6v4 for i386 from the links provided at http://substance.blackdown.org/java-linux/info.html but all i could find under the mirror sites i386/glibc sections is the V1 & V2 of JDK1.1.6. please guide me to the correct location for downloading JDK1.1.6V4 for i386/glibc version. --seshu satya seshu kumar dammu|4087332589|[EMAIL PROTECTED] http://www.cslab.uky.edu/~ksdamm0 Dream BIG. because dreams so small ... hath no power to move men More than just email--Get your FREE Netscape WebMail account today at http://home.netscape.com/netcenter/mail
Re: Delete all class files
> Thanks to everyone who wrote back! FWIW, the simplest solution for my > purposes turned out to be the addition of the following line: > > Markus Fritz wrote: > > > > Just use > > > > vpath %.class $(ROOT)/classes > > > > in your makefile > > > Cheers, > -Armen > Please, Just out of interest, what does ``vpath'' do ? > > > > > Armen Yampolsky wrote: > > > > > > I have a problem with this approach and using make, (probably because > > > I'm not using make correctly), in that if I use the -d option and use a > > > separate .class directory tree, make doesn't recognize the up-to-date > > > files there and recompiles everything anyway. I can never get the > > > "Nothing to be done for `CLASSES'" message when my Makefile looks like Cheers Peter -- import java.std.disclaimer.*; // "Dontcha just love the API, baby bop!" Peter Pilgrim Dept:OTC Derivatives IT, Deutsche Bank (UK) Ltd, Groundfloor 133 Houndsditch, London, EC3A 7DX Tel: +44-545-8000 Direct: +44 (0)171-545-9977 Fax: 0171-545-4313 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: JDK & native threads
On 23 Sep 1998 00:31:35 -0700, Anand Palaniswamy wrote: >> An alternative is Kaffe, but it's too incomplete to be usable right now. >> Is anyone working on producing a version of the JDK that uses native >> threads ? I don't know if Kaffe actually uses native threads... Since Native Threads do not exist on FreeBSD, it for sure does not use them there... >> I remember reading about some "problems" with this. What are the problems? > >The basic problem is that POSIX threads (the API implemented by >LinuxThreads) doesn't have suspend and resume primitives. These are >required because: > - Of the need to support the java.lang.Thread.suspend() and resume() >methods (these 2 have been deprecated in 1.2). > - Sun's implementation starting a new thread suspended. > - You need to suspend other threads during garbage collection. Well, these are interesting issues, but most of them can be handled with some thought. An OS-Layer I designed at Scala was to have threads much like Java does (and it is object based too...) Anyway, the goal was to be able to port this OS to run on top of other operating systems or to be its own operating system. We also have much the same threading features, including the creation of a thread in "suspended" state. Now, on some platforms this actually means starting the thread but hiding that fact by having our code then wait for a message/signal to continue before it jumps to the user level code. The suspend feature is tricky but we never defined how quickly it would suspend a thread. The reason we did not define this is because of multi- processor environments where the suspend call may be running at the same time as the thread that is being asked to be suspended. Thus it could not be used for synchronization. We delt with that by having the method calls notice the suspend and not continue until resumed. (Yes, in the method call interface, so there is some extra overhead to a method call if the underlying OS does not support the behavior) We did not have garbage collection, but that can also be handled in much the same way. However, this does bring up the performance issues. Given how the Linux threading model is designed, you will run complex multi-threaded code noticeably slower on single processor systems and maybe even with multi-processor systems, depending on what the code does. There is significant overhead to doing things like GC and monitor locking that could end up using enough extra resources that it becomes a net loss. (Now, the OS/2 threading model, for example, would be a very good match to the Java threading model. The Amiga "tasks" fit even better, but that does not help Linux...) >Note to friends of LinuxThreads: > >LinuxThreads FAQ indicates that one workaround is to post SIGSTOP and >SIGCONT signals and these are akin to suspend/resume. However, I >noticed that if a process flags has PF_PTRACED, the SIGSTOP isn't >really delivered, meaning I can't run the VM under gdb -- which makes >this option useless. I'll have to find an alternative solution for >suspend/resume. > >LinuxThreads uses SIGUSR1 and SIGUSR2, so it is not so embeddable. >Don't get me wrong -- I like LinuxThreads, I was impressed by the >cleanliness of its implementation, and it just works, but threads the >kernel really understood would be nice. Yes, they were nicely patched into the system, but a real threading model would be much better. Also, it would be nice if the number of threads were not hard limited. There is no excuse in today's world to have fixed tables for processes or threads. Someone should maybe look at how the Amiga handled "tasks" for an example of "unlimited" numbers of tasks with minimal to no impact on performance. >-Anand > >[1] Two caveats: >- compute bound threads can starve other threads. But there is a > un-supported -ts flag that makes the green threads VM time slice. There is nothing that says that a green-threads implementation may not timeslice anyway. The Java spec says that it does not have to, mainly so that Java can be made to run to spec on a large number of systems. >- native methods can short-circuit the wrappers and block. Native > methods in the JDK don't do this. This is an issue. JNI code should make sure it links with the green threads wrappers so that all of the blocking calls are handled correctly. (Or at least all of the blocking calls that it happens to have wrappers for) >Also System.in.read() is known to block the entire process on >Solaris green threads atleast (fixed in 1.2). The Linux port has this fixed now. The Solaris green threads version has this broken since they do not change the file descriptors for the STDIN/ STDOUT/STDERR to non-blocking file descriptors. This was done due to a problem outside the control of the Java group (the shell would get confused) but this has been addressed in Solaris (and is not an issue in Linux) Plus, with
Re: JDK & native threads
On Tue, 22 Sep 1998, Gerald Gutierrez wrote: > I'm starting to pull out my hair from the fact that the current JDK is > based on user threads. I can't call anything that can potentially block, > because everything will block. > Are you saying that if my application has 5 threads running, and one of them blocks on a blocking method (i.e., BufferedReader.readLine() on a client socket) then the 4 other threads are blocking (not running) also during this time?? Thanks, Mark
Re: JDK & native threads
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote on Wed, Sep 23, 1998 at 09:29:19AM - 0400: > Are you saying that if my application has 5 threads running, and > one of them blocks on a blocking method (i.e., BufferedReader.readLine() > on a client socket) then the 4 other threads are blocking (not running) > also during this time?? The answer depends on the operating system used. If all threads have the same priority, then a call to a blocking console I/O operation will block all other peer threads on Solaris, but will not on Windows. This is an area where the "write once, run anywhere" statement fails. The solution is to execute threads that perform console I/O with a lower priority. Alexander
Re: JDK & native threads
On Wed, 23 Sep 1998, Alexander V. Konstantinou wrote: > [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote on Wed, Sep 23, 1998 at 09:29:19AM - > 0400: > > Are you saying that if my application has 5 threads running, and > > one of them blocks on a blocking method (i.e., BufferedReader.readLine() > > on a client socket) then the 4 other threads are blocking (not running) > > also during this time?? > > The answer depends on the operating system used. If all threads have the > same priority, then a call to a blocking console I/O operation will block > all other peer threads on Solaris, but will not on Windows. This is an > area where the "write once, run anywhere" statement fails. The solution > is to execute threads that perform console I/O with a lower priority. > A call made by who? one of the threads? or by main? Thanks, Mark
Re: JDK & native threads
> (Ok, so on older versions, reads from STDIN/STDOUT/STDERR were a problem
> but this has been addressed)
>
Are you sure ? The following seems to indicate that at least
STDIN will block everything.
import java.io.*;
public class Threads extends Thread
{
public static void main (String[] av)
{
try {
Threads th = new Threads ();
th.setDaemon (true);
th.start ();
Thread.sleep (5000); /* Is the thread running ? */
System.out.println ("What's your name ?");
String strn = (new BufferedReader (
new InputStreamReader (System.in))).readLine ();
System.out.println ("Hello, " + strn + "!");
} catch (Exception e) {
e.printStackTrace ();
}
}
public void run ()
{
try {
while (true) {
System.out.println ("Waiting");
Thread.sleep (500);
}
} catch (Exception e) {
e.printStackTrace ();
}
}
}
Re: JDK & native threads
On Wed, 23 Sep 1998 09:29:19 -0400 (EDT), [EMAIL PROTECTED] wrote: > >On Tue, 22 Sep 1998, Gerald Gutierrez wrote: > >> I'm starting to pull out my hair from the fact that the current JDK is >> based on user threads. I can't call anything that can potentially block, >> because everything will block. >> > >Are you saying that if my application has 5 threads running, and >one of them blocks on a blocking method (i.e., BufferedReader.readLine() >on a client socket) then the 4 other threads are blocking (not running) >also during this time?? No... The JVM and the green threads wrappers make all of this work with the magic of select() and poll() and other such "wonderful" things. The problem comes when you use native methods and the native code blocks on something (either because it is not using green threads wrappers or because the blocking call is not part of the green threads wrapper) Then you will block. (Ok, so on older versions, reads from STDIN/STDOUT/STDERR were a problem but this has been addressed) Michael Sinz -- Director of Research & Development, NextBus Inc. mailto:[EMAIL PROTECTED] - http://www.nextbus.com My place on the web ---> http://www.users.fast.net/~michael_sinz
Re: JDK & native threads
On Wed, 23 Sep 1998 09:42:48 -0700, Gerald Gutierrez wrote: >> (Ok, so on older versions, reads from STDIN/STDOUT/STDERR were a problem >> but this has been addressed) >> > > >Are you sure ? The following seems to indicate that at least >STDIN will block everything. Yes, I am sure - you need to use the Linux port V4a to solve this. STDIN/STDOUT/STDERR were blocking file descriptors in previous ports. On Solaris they still are (until JDK 1.2 unless they do a JDK 1.1.7 maybe?) If you check the Java-Linux bug database (jitterbug) you will see that I was the one to report this and that Kevin was the one who did most of the work to address this. Michael Sinz -- Director of Research & Development, NextBus Inc. mailto:[EMAIL PROTECTED] - http://www.nextbus.com My place on the web ---> http://www.users.fast.net/~michael_sinz
JDK 1.1.6 Version 4a and VolanoMark 2.0
Thanks for the great port in Version 4a!
It fixes that socket timeout bug I reported here back in October 1997
against JDK 1.1.3. I was unable to reproduce the problem at all outside
of the VolanoMark benchmark or our VolanoChat product, but I'm grateful
someone figured it out.
Using the same VolanoMark 2.0.0 Build 137 that I used in my August
JavaWorld article, I get the new scores shown below -- a 37% performance
improvement over JDK 1.1.6 Version 2! From the stress tests I've run,
it seems to be very stable as well.
VolanoMark 2.0.0 Build 137 Loopback Test
Java virtual machine Scores Average (best 2 of 3)
- -
Linux JDK 1.1.6 v2230, 234, 233 234
Linux JDK 1.1.6 v4a 317, 321, 319 320 (+ 37%)
For the details on the test, see:
http://www.javaworld.com/javaworld/jw-08-1998/jw-08-volanomark.html
If anyone on the Blackdown Java-Linux Porting Team wants a copy of
VolanoMark 2.0, please let me know.
Thanks again,
John Neffenger
Re: JDK & native threads
>>> An alternative is Kaffe, but it's too incomplete to be usable right now. >>> Is anyone working on producing a version of the JDK that uses native >>> threads ? > >I don't know if Kaffe actually uses native threads... Since Native >Threads do not exist on FreeBSD, it for sure does not use them there... FYI, there are several alternate thread systems in (incomplete :-) kaffe. The old "unix-internal" resembles the green-threads (intercepting all blocking sys calls), "unix-pthreads" uses Posix threads (w/o the deprecated suspend/resumes), and "unix-jthreads" (which is a SIGIO based user thread system that doesn't do any polling). This became possible because the thread system is accessed (from the rest of the VM) via a separate ThreadInterface. And yes, there are custom ports which use kernel threads (via this interface). -- Peter
VISIBROKER FOR LINUX
Is there a version of VISIBROKER for Linux? if yes, where? else Is there an idl2java compiler for linux?
Re: VISIBROKER FOR LINUX
> Is there a version of VISIBROKER for Linux? Visibroker for Java will run on the Linux JVM. It is a 100% pure java CORBA implimentation. The ORB's and services are all implimented in Java, and yes it includes a idl2java and a java2idl compilers. Visigenic was bought by Borland and together they changed their name to Inprise. Check out http://www.inprise.com/visibroker/ > > if yes, where? > else > Is there an idl2java compiler for linux? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Deep Thoughts, By Jack Handey I can picture in my mind a world without war, a world without hate. And I can picture us attacking that world, because they'd never expect it. Todd Palmer Developer CallCenter Technology Inc [EMAIL PROTECTED] http://www.CallCenterTechnology.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
sdk 1.1.6 Sparc/linux kit problems? (fwd)
hi there Sorry to send this directly, but java-linux.org doesn't seem to exist anymore... I am lost.. hw: Sparc/Linux 1.0.9 Ultra/10 Sun machine...256meg memory RedHat 5.0 problem: Following the readme.linux instructions, I unpacked into /SDK-1.1.6/ Set up a link to /SDK-1.1.6/bin/javathen enter: $ java java was not found in /jdk1.1.6/bin/../bin/sparc64/green_threads/java As you see, it does not work I looked through the java script and see it is looking for a bunch of jar files, rt.jar, class.jar, etc. The sparc kit does not have them! Could that be the error? The is an 8MEG classes.zip in ./lib Also, if I try to run the executable, which is not recommended, I get an error: ./java: can't load library 'libjava.so' I do see it in ./lib along with a bunch of others I am lost. Where do I go from here? phil == Phil Hunt [EMAIL PROTECTED] System Administrator work: (603)424-5278 Internet Services of New England WWW: www.isone.net Merrimack, NH 03054"New England Internet for less"
