Date: Wed, 20 Mar 2002 22:37:24 -0800 From: Bill Huey <billh@gnuppy.monkey.org> To: Greg Lewis <glewis@eyesbeyond.com> Cc: java@FreeBSD.ORG, Bill Huey <billh@gnuppy.monkey.org> Subject: Re: Mozilla core... & HotSpot update Message-ID: <20020321063724.GA6657@gnuppy.monkey.org> In-Reply-To: <20020321142512.A65790@misty.eyesbeyond.com> References: <200203201509.PAA29782@sorley.cogsci.ed.ac.uk> <20020320201858.GA3125@gnuppy.monkey.org> <15512.61557.26582.852492@caddis.yogotech.com> <20020320233301.GA4011@gnuppy.monkey.org> <15513.7648.287464.414451@caddis.yogotech.com> <20020321000145.GA4319@gnuppy.monkey.org> <20020321142512.A65790@misty.eyesbeyond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 21, 2002 at 02:25:13PM +1030, Greg Lewis wrote:
> I see that Shudo-san has replied. I'm sure he is an excellent source
> of JIT knowledge :). Also, Fuyuhiko-san is one of the main OpenJIT
> developers, so between them they should be able to set you straight
> about JIT compilers. Just post the questions :).
The most difficult aspect of understanding this the shear runtime
complexity of the Solaris code itself where it does nutty stuff like
encapsulate all of the OS functionality within a C++ framework, resolve
threading reference at execution time and other wacky Solaris thingies
with their signal/threading libraries. The style isn't very familiar and
they use all sorts of crazy derived classes to deal with objects
with various allocation classes such as static, stack, cheap, etc...
It's been very confusing to attempt to understand. The callback stuff
so that HotSpot can manipulate a ucontext_t is also pretty nutty and
took me a while to understand why it was there in the first place.
I have never seen the use of a signal stack in that way before this
code tree and certainly manipulating the program counter, getting the
stack and stack frame are non-standard uses of it.
The entire compiler is protected by mutexes in all notable major
sections presummably because they like to have things as optimized
for threading as much as possible. They exploit weird constructor/destructor
calling conventions within a certain scope, etc...
{ // construct
MutexLock bigvar(constructor_argument);
...
if (bigvar.check_me_no_joke())
...;
} // destruct
Pretty nutty...
It's taken me a while to get my head around the whole thing (big picture)
enough to really make sense of it, while previously I was focused on the
very low level parts of the system and only dealt with it from a very
nuts & boltsy level. It's making much more sense now and I can switch
back and forth between all parts now and incrementally understand how
it those parts interact, while before I was just plain confused.
The plan here now is to skip the architecture specific directory since
that's pretty healthy now, os_cpu/linux_i486/vm/linux, and work on
the OS specific stuff next. It's now the most raw and needs the most
work.
I'm definitely converging closer to a workable system as I keep at it.
No doubt about that.
BTW, I would expect our version of HotSpot to be very fast for CPU
intensive tasks, since libc_r is implemented in userspace. Context
switches, dequeuing threads off a turnstile and rescheduling and things
like that should all be very fast because of this. I can't wait to
have somebody bench it to see if this is true or if I'm just completely
wrong.
;-)
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?20020321063724.GA6657>