Native Threading With A Linux JDK?

mikej asks: "I've always had issues with the native threading of Sun's JDKs on Linux, but have been able to get around the problems by using green threads. I've come into a situation where I absolutely must use native threads, and the Blackdown-derived 1.3 [J/S]DK from Sun simply doesn't cut it (context switing time, which is a Linux issue, is part of the problem as well). Is there a reliable (and reasonably quick) native-threading JDK available for Linux? I much prefer a Free or Open Source version, but if I have to start using commercial software to get this functionality then I have no choice. In addition, are there different Linux threading libraries available?"

Comments

IBM JDK

[steff77]

I don't know anything about it, but I am told IBM's JDK 1.3 is better than Sun's (I don't know in which sense). I don't know under which license it is published either. It is free for download, though. Stefan

Re:IBM JDK

[jmauro]

IBM's JDK is a closed source program, but it is very good. I'd recommend it. It is much faster than Suns (some tests by a factor of 2) but it is slower than Kaffe. Kaffe cannot run Java2 programs, only Java 1.1. It does use native threads.

Re:IBM JDK

[UberLame]

IBM also provides documentation in their developerworks web site on tweaking the linux kernel for better java performance.

Kaffe

[buttfucker2000]

Kaffe, an [the best] open source JDK, is your best bet.

It supports user-level threads (jthreads - recommended unless you want to spend weeks on each port to alternate platforms (of course you might require the speed of kernel threads - Java tends to be slow (although much of this is the overhead from the Virtual machine)) as well as standard Posix kernel threads.

The Sun JDK does a decent job...

[X]

Your problems are reliability and performance of the threading mechanism? Well, you could use Kaffe and tweak it to suit your needs, but let's consider this in more detail for a second.

The thread context switch time is indeed a Linux-wide problem. The latest 2.4-testX series does have some patches which will let the pthreads guys get around this problem, but unless you want to build it yourself, you are going to have to wait at least another 6 months for those changes to be well tested and rolled out. That being said Linux still manages to achieve high scores on VolanoMarks, so perhaps your problem lies elsewhere.

As far as stability, goes, the Sun JDK 1.3 is fairly stable by my count. On average it's been more stable than the IBM one (although the IBM one is sooooo fast)! If you are encountering a bug, I'd suggest:

• Reporting it to Sun's Bug Parade
• Downloading the latest Blackdown release and seeing if it's been fixed.
• Reporting the bug to the blackdown mailing list.

This is probably the easiest way to get a more stable VM.

Finally, if thread context-switch time is really that important to you, might I suggest that you've either got a flaw in your design or that Java is perhaps not the best solution for your problem. There are real-time extensions to Java, but without those, it's pretty hard to get decent performance guaruntees about those kinds of things for Java.

Why native threads?

[buttfucker2000]

I'm just curious: why do you need native threads?

Wouldn't you be better using C++? [Presuming you're using native threads for speed reasons.]

Or if there are other reasons for their use, wouldn't it be better to compile the Java source into native bytecode (using GCJ)? Although it wouldn't be as fast as C++ (by a factor of at least 3 times, according to tests), it would be at least somewhat faster.

Re:Why native threads?

[Anonymous Coward]

I'm just curious: why do you need native threads?

He probably doesn't like the lack of flexibility of ordering... perhaps he wants to make threads with higher priority than their parent.

I wish he'd be more forthcoming with the details; it could be an educational conversation.

I think he might want to try out HotSpot, if it's just performance. But it takes just a few seconds to spawn 10,000 threads on a midrange 'puter, optimizing VM or not...

Re:Why native threads?

[funkman]

Aggreed. Since java is generally slower than C++ or C. It may be time to rewrite code to a faster (less portable) language.

An alternative is identifying your slow code and rewriting those areas to native code. (which makes the Java application platform dependent but faster.)

Re:Why native threads?

[The Mayor]

One reason not to use C++: server-side programming. Java outperforms C++ in this instance, due to the per-request startup time incurred in C++. JSPs and Servlets make heavy use of object pooling. For server-side programming, Java kicks the crap out of native languages. Only mod_perl & mod_php handle more requests per minute than JRun, the current servlet engine performance leader.

Compiling the Java source into native bytecode doesn't help. First, you lose all the benefits of server-side Java (the program ends up just like C++ in this instance--no object pooling).

Now, I have no idea what the original author is trying to do. But this response simply doesn't make sense for server-side programming. Generallly, server-side programming is one area that is well suited towards creating large amounts of threads.

One thing the author could try to do is to either run WinNT or Solaris. Both of these OSes have much more effective threading models than the 2.2.x kernels (shudder--WinNT is better at something than Linux!). I'd recommend Solaris, personally. It scales much better to large hardware. And you still get the Unix environment.

YMMV.

Re:Why native threads?

[jmaslak]

He might need the native threads to take advantage of a multi-processor box... Green threads/process threads will be ~50% slower on a two processor box, and much slower than that on a medium sized server (8-16 processors). I can't imagine anyone even thinking of using Java on a truly large box, but you would get even more performance increase in a well-designed application.

Re:Why native threads?

[The Mayor]

Write to my e-mail address. It's valid. No changes necessary.

Strange Java problems

[digitaltraveller]

I wrote a simple graphics program in Java that behaves very odd under Linux. What happens is the application requests a number of edges and then draws a polygon which rotates the even numbered vertices clockwise and odd numbered vertices anti clockwise . This was done at the same speed to create a kind of neat kalidescope (sp?) graphic. This is a very simple 10-15 line program. Well, it originally worked fine when I had Mandrake 7.1 with the JDK 1.3 RPM that Sun released in October when I tested it. So for various reasons, I re-installed my Mandrake system and re-installed the same JDK. Now the program will not work properly, it only rotates if an odd number of edges are entered and when it does that, it doesn't display the graphic properly. Switching between native and green threads doesn't help it. I'm mystified.

Very, very odd. Anyone have any idea?

JDK 1.3 From Sun

[MarkX]

Have you tried the latest JDK from Sun? I have tried it, working with Enhydra, and it seems very good.

Later,

Mark

Re:JDK 1.3 From Sun

[RossyB]

"and the Blackdown-derived 1.3 [J/S]DK from Sun simply doesn't cut it"

Yes, he has.