Date: Thu, 28 Nov 2002 16:34:53 -0800 From: Bill Huey (Hui) <billh@gnuppy.monkey.org> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Alexey Zelkin <phantom@FreeBSD.org.ua>, freebsd-java@FreeBSD.ORG, "Bill Huey (Hui)" <billh@gnuppy.monkey.org> Subject: Re: PATCH - changing libc_r to use *context() (fwd) Message-ID: <20021129003453.GB1818@gnuppy.monkey.org> In-Reply-To: <Pine.GSO.4.10.10211280752320.24795-100000@pcnet1.pcnet.com> References: <20021128143403.A98438@phantom.cris.net> <Pine.GSO.4.10.10211280752320.24795-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 28, 2002 at 08:00:41AM -0500, Daniel Eischen wrote: > No, it shouldn't be much slower, at least for i386. Each arch > now has a MD header file which is used by the thread scheduler. > This file has to define THR_SETCONTEXT, THR_GETCONTEXT, and > THR_SWAPCONTEXT. For i386, we provide userland versions of > the *context() calls. For other archs that just want to get > up and running, they can define these to be the system calls. > And since libc_r is going away eventually, there's really > no nead for optimizing them for other archs anyways. I looked at the patch and it's exactly what we need for doing the kind of ucontext trickery we're doing now and need in the future. ;) Both native versions of J2SE are i386 only at this time, so it'll fine for folks like us, not sure what you're having to deal with at this time for other architectures. If compilation of those changes can be made architectural specific, then putting in place will be nice. That's up to you though. I'm getting the register values (esp, eip, ebp) out of the backing jmp_buf for now, which is sufficient at this time and the need for a ucontext isn't terrible urgent. I'll switch once that's all in place and then "fast path" the entire thing. > I don't see them working on -stable, since it doesn't have > *context() system calls. It could work for i386, but there > are some other problems in the kernel that may prevent it > anyways (floating point state is not aligned). > > And on -current, this patch isn't quite right. FPU state > isn't being properly restored and the kernel needs to be > fixed to align the FPU state also. I'm targetting all of my stuff for -current at this time because of the threading issues. bill 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?20021129003453.GB1818>