Date: Sat, 25 Aug 2001 09:57:46 -0700 From: Arun Sharma <arun@sharmas.dhs.org> To: Fuyuhiko Maruyama <fuyuhik8@is.titech.ac.jp> Cc: java@freebsd.org Subject: Re: JVM and native threads Message-ID: <20010825095746.A1015@sharmas.dhs.org> In-Reply-To: <55vgjcqv87.wl@tripper.private>; from fuyuhik8@is.titech.ac.jp on Sat, Aug 25, 2001 at 07:39:36PM %2B0900 References: <20010824233304.A32099@sharmas.dhs.org> <55vgjcqv87.wl@tripper.private>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 25, 2001 at 07:39:36PM +0900, Fuyuhiko Maruyama wrote: > 1. NGPT is simply a user space implementation of multi-threading > on non-SMP system. In this case, there's no difference between > FreeBSD's own pthread (libc_r) and NGPT from the scalability's point NGPT is the only way I can have one process use multiple CPUs on my SMP system (apart from the linuxthreads). > 2. NGPT is partially an rfork based multi-threading on SMP system, it > makes ugly processes in process table and outputs of ps is also > ugly (This may be fixed only in Linux environment with NGPT's kernel > patch). On the other hand, FreeBSD folks have a plan to introduce a > brandnew multi-threading mechanism (KSE based one). I think KSE > based threading is the way to go. It will have much better > scalability than rfork based threading. Of course, there is no > working code yet is a serious weak point of KSE based threading. Exactly. I remember going to a meeting to discuss KSE in Foster City, about two years ago. KSE sounds cool, but till it happens, NGPT might be a good work around. > 3. NGPT is LGPLed, so it will never be imported in the FreeBSD's > base tree because FreeBSD has its own implementation of > multi-threading. Sure, NGPT will remain a port. But Java is not going into the base system either. License objections if any, should be towards the JDK. I think the NGPT license is relatively benign :) > > In fact, the most important point to think how to use threading > library for native threads is derived from the fact that Java VM uses > some facility not covered by POSIX thread (e.g. Java VM needs to know > the machine state of all threads such as stack pointer, program > counter and another registers). Therefore, the implementation of Java > native threads used to depend on the threading library so much. > I'm sure, these kinds of issues can be solved without much difficulty - just add a couple of _np calls to the package. I'm not saying that NGPT is an end-all solution to world hunger. Just that it may be worth looking at in the short term, until we have a production quality SMP capable thread package in the base. That said, I've run into a couple of problems: - Linux focus of the NGPT project. I suspect that this is more of a corporate thing, but they haven't shown any eagerness to merge my patches in. - Low quality of the 1.0.1 release. I spent a day fixing it, sent patches to the developer list, without a response. http://www-124.ibm.com/pipermail/pthreads-devel/2001-August/thread.html I'll update the NGPT port to 1.0.1 soon. -Arun 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?20010825095746.A1015>