Date: Sun, 26 Aug 2001 22:12:38 +0900 From: Fuyuhiko Maruyama <fuyuhik8@is.titech.ac.jp> To: Arun Sharma <arun@sharmas.dhs.org> Cc: java@freebsd.org Subject: Re: JVM and native threads Message-ID: <55heuv0xtl.wl@tripper.private> In-Reply-To: <20010825095746.A1015@sharmas.dhs.org> References: <20010824233304.A32099@sharmas.dhs.org> <55vgjcqv87.wl@tripper.private> <20010825095746.A1015@sharmas.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At Sat, 25 Aug 2001 09:57:46 -0700, Arun Sharma wrote: > > > 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 :) O.K. Licence issues may not be so important. But the result, never in the base system, makes quite serious problem for Java. For example, mozilla uses multi-threading library and of course the current FreeBSD port uses system pthread library (libc_r). Our BSD native J2SDK will have Java-Plugin for mozilla and it must use exactly the same threading library as mozilla uses. In this case, we have only three alternative: 1. Use libc_r in J2SDK. 2. Use the same extra threading library both in mozilla and J2SDK. 3. Giveup Java-Plugin. How do you think about this? Using libc_r in J2SDK is most reasonable alternative, isn't it? This isn't mozilla specific, Java is not only the java command but also Java environment as a program component that can be used in other programs via JNI. > > > > 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. Yes, I also think we need to define some _np calls. To do so, we need to consider what APIs are really needed, defined APIs are sufficient and general enough. We must spend more time to discuss about this issue. > 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. NGPT on FreeBSD achieves production quality before KSE based threading isn't clear I think. > 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. I'll try it ;-). -- Fuyuhiko MARUYAMA <fuyuhik8@is.titech.ac.jp> Matsuoka laboratory, Department of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering, Tokyo Institute of Technology. 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?55heuv0xtl.wl>