Re: Green/Native threads
I don't know much about the specifics of linuxthreads, but pthreads are usually implemented with a group of kernel threads (supplied by clone() syscall in this case, and they're definitely "light-weight" processes). Perhaps, they've been referred to as "heavy-weight" just as a term relative to green threads, since green threads have all of their state switched in user-level(?) calls sigsetjmp and siglongjmp. >From the discussion so far, it sounds like Java green threads are supposed to provide unfair behavior (computationally bound threads can indefinitely preempt like or lower priority threads). I haven't looked at the native thread Java scheduler, but I presume that like priority, runnable Java threads would be mapped to like priority, runnable pthreads. In which case, the green threads and native threads will differ wildly in their scheduling behavior. David On Sun, 7 Feb 1999, Dimitris Vyzovitis wrote: > Gerald Gutierrez wrote: > > > > > > > Non-Java processes don't have the problem because "processes" are > > heavyweight native threads, essentially. Non-Java threads MAY have the > > problem if they are not native threads. > > > > Assuming you are talking about Linux when you talk about G++, yes Linux > > implements a time slicing mechanism. I don't think it implements preemption. > > > > This makes me wonder. > AFAIK, according to their definition, threads are supposed to be "lightweight" > processes. > How are linuxthreads actually implemented? ie, do we get the real lightweight > process that we are supposed to get by the pthreads definitions? > The descriptions seen in the discussion so far imply that this is not the case, > while it should be (and we should not have to worry that much about overhead ;-} > ) > > thanx, > Dimitris > > > >
Re: jvm source
Get the a license agreement and then the sources at: http://www.java.sun.com/products/jdk/1.1/source.html Then download the relevant source patch from: http://www.blackdown.org (To my knowledge, the patch for Java2 isn't complete, yet. However, looking at the Solaris build is a good place to see what it will look like.) Cheers, David e-mail: [EMAIL PROTECTED], the rest: http://www.csrd.uiuc.edu/~dcraig On Wed, 10 Feb 1999, Ajay Jayaraj wrote: > hi, > Do you license out the JVM linux source for educational/research > purposes ? > > > ajay >
Re: jdk 1.1.7.1a / tya 1.2v3 performance?
Is symcjit, the Symantec JIT running on WinNT? I'd greatly appreciate finding out more, but to my knowledge the available JITs are TYA and shuJIT for the port of Sun's VM and the JIT within Kaffe. shuJIT doesn't appear to be mentioned very often in performance comparisons in this list. Its website boasts performance results that are usually better than TYA 1.2v3, and I'd be curious to hear about it's ease of use. (http://www.shudo.net/jit/) David Craig e-mail: [EMAIL PROTECTED], the rest: http://www.csrd.uiuc.edu/~dcraig On Wed, 17 Feb 1999, Artur Biesiadowski wrote: > "Joseph H. Buehler" wrote: > > > That's about 14 microseconds per loop, which is very slow, given what > > the code is doing on each pass through the loop: setting a bit in a > > bit array. > > > > Preallocating the BitSet doesn't change things. I installed tya using > > egcs, and tried various optimization flags, and some minor variations > > in tyaconfig.h, but the timing does not vary a whole lot. > > > > Do these results seem reasonable? > > You have not given results for jdk without tya. I've done few tests, and > tya gives me 2.5x speedup on this test. For comparison symcjit is about > 16x faster. After some divisions I came up with following numbers (all > are quite rounded) > > 5000 cycles per iteration for plain jdk > 1900 cycles per iteration for tya > 300 cycles per iteration for symcjit > > I think that that are quite reasonable number if you think about all > things that have to be done. For set method there are about 4 method > calls that need to be done + one synchronization. Additional problem is > that BitSet uses longs internally which causes a major slowdown on > intel. > > Try to rewrite your benchmark using explicit array of ints, preallocated > to correct size, and then just fill it bit after bit. This way you will > get bare speed of java, without BitSet overhead. BitSet was not designed > to perform as buffer for image manipulation. > > Artur >
Re: Multi-Threading: Preemptive?
Java doesn't define how threads of the same priority share cpu time In some VM implementations the sharing is fair. On others, such as the port you're probably using, one thread preempts the other indefinitely. Congrats on an elegant workaround. :) Cheers, David e-mail: [EMAIL PROTECTED], the rest: http://www.csrd.uiuc.edu/~dcraig On Wed, 24 Feb 1999, Chris Raser wrote: > > Greetings all! I've got a little problem with the handling of > threads on my machine. (I'm using RH5.1 w/ your jdk117) > > I'm finding that, given two threads of the same priority, the one > that's currently getting CPU time will starve the other one until an > explicit yield() or sleep() is reached. Is there any way to fix this? > > I've got a reasonably elegant workaround, but it's a workaround > nonetheless, and I'm reluctant to make it a standard part of my code. (As > I'll have to do in order to ensure that my code will work on all three of > the platforms that it will be running on.) > > Any help or insights you guys can offer would be appreciated. > Thanks! > > -chris > > *** > The most important thing in the programming language is the name. A > language will not succeed without a good name. I have recently invented a > very good name and now I am looking for a suitable language. > -- D. E. Knuth, 1967 > *** > > > > -- > 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: Multi-Threading: Preemptive?
Seeing as how grad. students seem to be the only one's awake at this hour and reading/posting to the list, I can get away with assuming I understand everything that is going on his code. What he did was write his own scheduler, (the MAXPRI thread). It probably sleeps for fixed period of time, acting as the clock tick. On the pseudo clock tick, it switches in the next thread, by elevating its priority or resuming it. (All of the work threads are assumed to be computationally bound. I/O bound threads don't have this problem.) Perhaps, the Java folks felt it was better that users customize their scheduling rather than have everyone pay the overhead for fair share scheduling. (Questionably little overhead. :( ) -d e-mail: [EMAIL PROTECTED], the rest: http://www.csrd.uiuc.edu/~dcraig On Wed, 24 Feb 1999, Moses DeJong wrote: > On Wed, 24 Feb 1999, Chris Raser wrote: > > > > > On Wed, 24 Feb 1999, David Craig wrote: > > > Java doesn't define how threads of the same priority share cpu time In > > > some VM implementations the sharing is fair. On others, such as the port > > > you're probably using, one thread preempts the other indefinitely. > > > > > > Congrats on an elegant workaround. :) > > > > > Actually, it's not my own invention, and I'm sure that others have > > done something similar. All I did was create a thread of "MAX_PRIORITY" > > that just goes right to sleep. It preempts everything else, then gives > > the little guys a chance to do their thing. (and I write a minimum of > > extra code to keep everything moving) Maybe "honorable hack" is a better > > term than "elegant". > > > > Thanks for the info- my java-idealism was getting just a little > > out of controll there for a second... ;) > > > > -chris > > > I do not mean to rip on your code or anything, but if you require a > big hack like that then something must be wrong with the design of > the program. Please do not take that the wrong way. Why exactly do > your threads starve each other? Are they polling or something? Most > of the time a polling process can be replaced by a signal based > process and you will end up saving a lot of wasted CPU time. > Just a thought. > > Mo DeJong > dejong at cs.umn.edu > > > -- > 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: Graph Package
Perhaps this will work for your needs? http://www.jrefinery.com/jfreechart/index.html --- yangyuex <[EMAIL PROTECTED]> wrote: > > > > Who can tell me where I can find a good Graph > Package? > I already find some things from IBM and JDSL. But I > am > not satisfied with them. > Who can suggest some others? > > Thanks > yangyuexiang > > > > -- > To UNSUBSCRIBE, email to > [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > __ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
