Date: Tue, 11 Dec 2001 11:29:25 -0700 From: Nate Williams <nate@yogotech.com> To: Bill Huey <billh@gnuppy.monkey.org> Cc: Nate Williams <nate@yogotech.com>, absinthe@pobox.com, shanon loveridge <shanon_loveridge@yahoo.co.uk>, freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <15382.20613.76791.634824@caddis.yogotech.com> In-Reply-To: <20011211104902.GA8293@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Continuing to play devil's advocate here. I believe native threading is a step in the right direction, but it's certainly not the panacea that is implied here. ] > > > My understanding is that native threads were not dependent on kernel > > > threads; that is, native threads are there to, among other things, > > > reduce I/O overhead. I understand as much to know that to go SMP inside > > > of the Java VM requires kernel threads. > > > > Again, the internal green threads implementations uses the same tricks > > as do native threads to reduce I/O overhead. > > With the current technical direction, yes, that's true. But when I think > of native threading I'm thinking about the entire platform that come with it, > proper JNI, HotSpot, etc... So it's a umbrella for all those facilities. Again, you can do everything (including HotSpot, if you're so inclined) without the native threading. However, it's *easier* to do without green threads simply because Sun is using the pthreads API, so most of the work is already done for us *IF* we use pthreads. JNI on the other hand works fine either way, although if you don't use pthreads, then you have to work alot harder to create 'safe' code. (You can't link against libc_r and expect it to work.) > > > But again, the way I understand it is that by talking to a VM built > > > around pthreads, that some performance gains can be had. So I guess > > > that (until SMPng becomes a reality) what I'm asking is whether a native > > > VM build exists around pthreads. > > > > It's getting close, but as I stated above, for now it doesn't help much > > other than make it easier to port things such as HotSpot which use the > > PTHREADS API, unlike the JVM which allows you to use the older green > > threads technology. > > But the thing here is that having it fully working in the first place > allows for some pipelining of work from various server side clients to be > upwardly workable with kernelized threading is functioning. *ABSOLUTELY *TOTALLY* agreed. > > Also, JDK1.4 no longer has the green threads support, so we must use > > the native threads API. > > Which make native threading even more important to get it going now so > that bugs can be hammered out when a 1.4 attempt gets going so that it > hits the public in the quickest and most mature form possible. In my experience, Sun changes things so much between minor releases that it may not be as helpful as we'd like. From JDK1.0 -> JDK1.1 -> JDK1.2 -> JDK1.3 things changed enough that it wasn't *that* helpful to get the bugs hammered out. However, it did let us know that it was possible to have a stable JVM on FreeBSD, so in that respect we know that if it doesn't work reliably, then it's a problem with not getting everything moved over from the previous port, not an OS problem. > The whole point in getting native threading going was to make the FreeBSD > JVM *big time* in spite of the failure to get a commercial venture > to back this (Sun, BSDi before I came along, etc...). This is where we disagree. > Then this kind > "green threads is perfectly fine" juvenile attitude will properly die > and be replaced by a "Our JVM is better than yours. yes, really, *PLEASE > BITE ME*" and not this weak willed tone that folks are currently using > in the BSD community. Now suck that down. ;-) You're certainly entitled to that opinion, but that opinion seems more juvenile than the original one. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15382.20613.76791.634824>