Date: Wed, 20 Mar 2002 12:18:58 -0800 From: Bill Huey <billh@gnuppy.monkey.org> To: Richard Tobin <richard@cogsci.ed.ac.uk> Cc: java@FreeBSD.ORG Subject: Re: Mozilla core... & HotSpot update Message-ID: <20020320201858.GA3125@gnuppy.monkey.org> In-Reply-To: <200203201509.PAA29782@sorley.cogsci.ed.ac.uk> References: <200203201509.PAA29782@sorley.cogsci.ed.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 20, 2002 at 03:09:32PM +0000, Richard Tobin wrote: ... > It turned out that Mozilla was printing out a stack backtrace before > dying, which I didn't see at first because it was going to /dev/ttyv0 > (I started mozilla from a twm menu). It was fairly easy to track down > the function in question, and then it was just a matter of staring at > the code. What you did was good and very perceptive. > It would have been a lot quicker if I could work out how to rebuild > just the (very small) relevant parts of the JDK after making an edit, > rather than waiting while it does a bunch of Java compilations. Just go into the make system subtree for that section and recompile it. That generally works and is what I was doing to propagate changes in the hpi/ library and I would think something like that would also exist for the Motif/awt layer. ... Debugging the Java runtime is just shear hell which is why I was curious as to how you figured it out that quickly. Understanding runtime typing system and related JNI glue stubs is just flat out non-trivial, which is what you were dealing within the Motif layer. Somebody should write a primer on virtual machines and the supporting JNI layer. I personally haven't seen much of the code in that section so I can't gauge how obvious the bug was relative to rest of the code, but having other people like you that can fix those things is good since I know now that a single person can't do the entire JVM port alone properly. That frees up developers to work on other things. I'll have to look at it some time to get an idea of what's going on... :-) "HotSpot" BTW, HotSpot is getting closer. I've delete all of the Solaris LWP code rather carefully and what's left is: [OS glue layer] 1) There's a couple of problems with interruptable IO that are a bit semantically confusing such as the SYSV and BSD behaviors of a syscall during the delivery of a signal. Should it return EINT like in SYSV ? I'm going to have to look at the libc_r system to see how async IO wrappers are collected and the signaling behavior. 2) Fill in all the pthreads creation related code and get rid of all the Solaris-isms. This is the least complete of the sections, but is what I'm going to work on next. [CPU/architecture specifics] 3) Safe-point handling that deals with exceptions thrown in the middle of a JIT block still needs to be fully understood and verified. The call back framework during SIGUSR1 supporting the manipulation of ucontext_t's is now done. That supports the safe-point system. This section is almost complete after the work I've done over the last couple of days. That's all. ;-) 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?20020320201858.GA3125>