Date: Tue, 11 Dec 2001 12:59:09 -0700 From: Nate Williams <nate@yogotech.com> To: Joe Kelsey <joe@zircon.seattle.wa.us> Cc: freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <15382.25997.525752.48613@caddis.yogotech.com> In-Reply-To: <15382.25038.873386.878424@zircon.zircon.seattle.wa.us> 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> <15382.20613.76791.634824@caddis.yogotech.com> <15382.25038.873386.878424@zircon.zircon.seattle.wa.us>
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. > > ] > > Native threading is *required* for the mozilla plugin. > > > Again, you can do everything (including HotSpot, if you're so inclined) > > without the native threading. However, it's *easier* to do without > > I beg to differ. The green threads code is full of bugs and does not > work properly. I *really* beg to differ here. How much experience do you have with the green threads code vs. native code? The green threads code is very robust. > This is probably why 1.4 has dropped green threads. No, it was dropped for marketing reasons. > It is literally impossible to get the mozilla plugin to work with > green threads without spending a lot of time fixing bugs in the green > threads code. Again, there are no bugs in the green threads code. There are assumptions in the plugin code that no longer work due to green threads, but that's because the plugin folks never tried to get things working under green threads. > Nate, *you* may have trivial applications that do not rely on > extensive use of threads. I don't know. How does 10K threads sounds to you? Pretty trivial, huh? The application ran fine under NT, 95, 98, Solaris, FreeBSD, and Linux, without *ANY* modifications. At any time we had about 100-400 threads in active RUNSTATE. The appliation *rocked*, and performed about 3-5X faster than the native C application that it replaced. (Using threads allowed us to use a more effecient implementation and algorithms, plus since the I/O was the main bottleneck, Java was just as fast as native code.) > However, any attempt to use real threads to do real > work falls flat when you attempt to use green threads. Go ahead and > prove me wrong by making the plugin work with green threads. I have no need to do so. All of my work was done using real applications. I *personally* would never consider using Java inside of a WWW server. There are too many unknowns and security issues for me to consider deploying it, so I have absolutely no modification to do so. All of my Java work would be done in an application, or on the server where the plugin isn't used. That's not to say that it's not useful to you, but having spent 3 years doing FreeBSD/JDK development, I no longer have time to do the things I want to do, let alone the things that I have no interest in doing. However, I didn't want to see misinformation spread about the performance/usability of green threads vs. native threads. If/when kernel threads are implemented, using the native threads interface will be a big boost (assuming we have a PTHREADS API for accessing kernel threads). Otherwise, the green threads performance vs. the existing 'userland' native threads doesn't buy us much, except for having a standard API that many newer parts of the JVM use. (HotSpot for example). Performance is *NOT* the issue, but standard API's are. 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.25997.525752.48613>