Date: Sat, 25 Aug 2001 19:39:36 +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: <55vgjcqv87.wl@tripper.private> In-Reply-To: <20010824233304.A32099@sharmas.dhs.org> References: <20010824233304.A32099@sharmas.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, At Fri, 24 Aug 2001 23:33:04 -0700, Arun Sharma wrote: > > I saw some discussion about Java VMs and native threads on this list. > I'd request you folks to take a look at NGPT, if you haven't already. > > http://www.freebsd.org/cgi/ports.cgi?query=ngpt&stype=all > > It's working well for me in porting Intel ORP (a BSD licensed > Java VM) to FreeBSD. I don't have any attention to attack you, but I don't think NGPT is the solution for us. There are some reasons: 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 of view. FreeBSD already has an almost completed implementation of user space multi-threading. I think it is more important to polish libc_r than to introduce another wheel (NGPT). I know you have met some problem related to signal handling on libc_r's multi-threading and it is still exist. Using NGPT is just a workaround for you, isn't it? 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. 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. 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. We should have APIs relative to multi-threading not covered by POSIX. Otherwise, the binary release of JDK may have versioning problem (binaries are needed to specify the environment like, for 4.4-RELEASE, for 4.4-STABLE-20011224 or for 5.0-CURRENT-20010825... it's really a nightmare). -- 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?55vgjcqv87.wl>