Date: Sat, 23 Mar 2002 00:29:32 +0900 From: shudo@computer.org To: nate@yogotech.com Cc: java@FreeBSD.ORG Subject: Re: Mozilla core... & HotSpot update Message-ID: <200203221529.AAA18204@cafe.muraoka.info.waseda.ac.jp> In-Reply-To: <15514.30168.252188.732486@caddis.yogotech.com> References: <15514.28841.407418.877991@caddis.yogotech.com> <20020322000416.GA1670@gnuppy.monkey.org> <15514.30168.252188.732486@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Nate Williams <nate@yogotech.com> > The overhead of compilation is why HotSpot does a better job than > Standard JITs. It only compiles a small portion of the program at a > time, and can even decompile parts of the program if they fall out of > use. (Resources et. al.) Concerning compilation strategy on which a JIT determine to compile a method, this web page give us a clue. Java HotSpot VM Options http://java.sun.com/docs/hotspot/VMOptions.html It says: Flags and Default: -XX:CompileThreshold=10000 Description: number of method invocations/branches before (re-)compiling [10,000 -server, 1,500 -client] Sun's HotSpot VMs choose methods to be compiled according to the invocation/branch counter of each method. IBM JDK does the same, but it count branches in a different way from invocations. The JIT of IBM JDK may gives respective weights to invocation and branch. Last year one of the developers of IBM JITC said the threshold of the JIT is 2000. Even many of JITs called `standard' or `traditional' JIT here do the same. For example, Borland Java 2 JIT (*) compiles a method called twice. ShuJIT compiles a method when it has been called 10 times if it belongs to a system class (i.e. java.lang.* and java.io.* and so on). (*) Now we cannot obtain this JIT on web. These techniques, which are kinds of lazy compilation, outline one of limitations of JIT development independent of JVM. I suppose Classic VM now. A JIT can count invocations by itself while an interpreter working. But a JIT cannot count branches performed by the interpreter. > The last talk I heard on > HotSpot implied that they are using a single thread for compilation, > which is similar to the pseudo-single threaded garbage collector. (The > GC process can involve more than one thread, but only a single thread > can be active at a time). > The complexity/overhead of multiple GC's and compilation *far* > outweighs the benefits. IBM JikesRVM (formerly known as Jalapeno) also has one thread dedicated to JIT compilation. They insist this is not a problem. ShuJIT compile methods concurrently. Each thread can compile one method at the same time. An instance of a data structure for JIT compilation (struct compiler_context) is created for each compilation and an instance does not interfere each other. Of course, shared information is guarded with locks. Kazuyuki Shudo shudo@computer.org http://www.shudo.net/ 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?200203221529.AAA18204>