tag:blogger.com,1999:blog-75899419623504039802012-02-16T03:58:17.126-08:00Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.comBlogger191100tag:blogger.com,1999:blog-7589941962350403980.post-35559480393515474262010-08-28T21:51:00.000-07:002010-08-29T00:56:52.915-07:00

A common order used in an English dictionary is called the lexicographical order (or the alphabetic order). The same order can be used to sort binary data where bytes are letters and arrays of bytes are words. It is in fact commonly used to sort binary data or sequences of bytes (e.g., a compressed data or binary-encoded data). Those bytes are usually unsigned. However, there is no standard

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-424064763063235902010-06-26T22:33:00.000-07:002010-06-26T22:37:05.598-07:00

Back in April, I was voted in and joined the OpenJDK HotSpot group. Here's a link to the call-for-votes email thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-April/002866.html Here's the list of people in various groups of the OpenJDK project: http://db.openjdk.java.net/people I thank Chuck Rasbold, who coordinated and hosted the voting process, and those who voted for my

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-63009509842240581472010-06-26T22:27:00.000-07:002010-06-27T21:08:53.171-07:00

I worked on a small improvement on the Hotspot server compiler. Here's the mailing list thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2010-April/003054.html Here's the committed change: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d7f654633cfe The Short/Character.reverseBytes() methods swap the bytes within the 2 byte short or char values. This is commonly

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-74361982957799754882010-02-09T12:41:00.000-08:002010-02-16T20:56:55.551-08:00

The other day, I contributed a patch that lets Hotspot Server compiler emit shorter multiplication sequence for long (64bit) multiplications. Here are some links: The patch + the commit message: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e8443c7be117 Sun bug: http://bugs.sun.com/view_bug.do?bug_id=6921969 Mailing list posts:http://mail.openjdk.java.net/pipermail/

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-76994156284393890592009-12-29T21:15:00.001-08:002009-12-29T22:52:13.815-08:00

There are two JVM flags/options that control how many GC threads are used in the JVM: ParallelGCThreads and ParallelCMSThreads.ParallelGCThreadsThis flag controls the number of threads used in the parallel garbage collector. This includes the young generation collector used by default. If the parallel GC is used (-XX:+UseParallelGC) or turned on by default on a 'server-class' machine, this is

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com2tag:blogger.com,1999:blog-7589941962350403980.post-83077872499139130182009-12-29T21:14:00.000-08:002010-06-26T22:40:42.808-07:00

A basic build instruction was described here. But the full build takes long. Here are the variables that I use to build OpenJDK faster for everyday builds: NO_DOCS=true. This causes the build not to generate the javadoc docs for the JDK source code, which isn't very useful for daily engineering. NO_IMAGES=true and DEV_ONLY=true. By default, the JDK makefile builds the JDK and the JRE images (as

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-54668975094756016152009-12-29T21:13:00.000-08:002009-12-29T23:10:14.916-08:00

Have you wondered what consumes memory in the JVM process. Here are the most of the list:The Java heap. The maximum size is controlled by flag -Xmx. This is where Java objects are allocated.The permanent generation (perm gen) heap. The maximum size is controlled by -XX:MaxPermSize. The default is 64MB on Linux/x86. This is where the JVM-level class metadata objects, interned strings (

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com2tag:blogger.com,1999:blog-7589941962350403980.post-36622712005495884202009-07-29T10:29:00.000-07:002009-12-29T22:47:00.336-08:00

I worked on a patch to fix a bug in the Pisces renderer: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fb03586d68b6 http://bugs.openjdk.java.net/show_bug.cgi?id=100030The bug was that a circle was rendered like a 'C' shape, that is, the right most edge of the circle wasn't rendered properly. It turned out that there was a off-by-one error.And there are a few more bugfixes in progress: https://

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-49968718234692394152009-07-29T10:25:00.000-07:002009-12-29T21:56:06.134-08:00

Here's my latest contribution to OpenJDK:http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fd50a67f97d1The patch fixes a server compiler crash that happens in a very rare condition, described here. A key attribute of the server compiler IR is that an instruction must dominate all its inputs. However, in the function remix_address_expressions(), this property was violated and caused a crash

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-82113535246551252352009-04-10T17:26:00.000-07:002009-04-10T18:05:55.850-07:00

I encountered an event dispatch bug in JVMTI. See here for the communication on the openjdk mailing list. Here's a summary of what happened.According to the JVMTI spec, no JVMTI events should be sent during the JVMTI dead phase (after the VMDeath event was sent). However, I observed that the CompiledMethodLoad and CompiledMethodUnload events were sent during the dead phase after the

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-19705011702482528902009-03-16T17:05:00.000-07:002009-03-16T17:18:21.622-07:00

I'm not really a Java 2D person, but I contributed a small bugfix to OpenJDK for the miter line join rendering in the Java 2D Rendering Engine:http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9318628e8eeeWhat's miter line join? For a quick tutorial on the basics of Java 2D rendering, see this page from the Java tutorial:http://java.sun.com/docs/books/tutorial/2d/geometry/strokeandfill.html

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-24272596350756263292009-01-25T21:43:00.000-08:002009-01-25T21:52:00.184-08:00

I ran across a CMS crash bug in Hotspot 10 b19 (OpenJDK6 b11), which is described here:http://bugs.sun.com/view_bug.do?bug_id=6722116The symptom is that VM crashes in the concurrent GC thread at the following stack trace (with mangled symbols):_

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-50685494429694723272009-01-14T21:23:00.000-08:002009-01-25T21:56:32.499-08:00

This week I have been investigating the issue of mysterious (primitive) int array objects showing up in a heap dump (generated by the jmap utility or the Hotspot MXBean.) They are mysterious because they do not have any references to them (appears to be dead objects) according to the jhat output.Today I learned that the garbage collectors may fabricate fake int array objects in certain cases. A

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-71825884306025817532008-12-31T18:24:00.000-08:002009-01-25T21:57:12.126-08:00

I encountered a server compiler crash which happens in a Google server. Here's a link to more details:http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2008-September/000320.htmlIt appears to happen in the split-if graph transformation during the loop optimization. It only happens in a big Java server and I couldn't create a small test for the crash. I was able to create a small patch

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-55599402246268535642008-12-31T18:08:00.000-08:002008-12-31T18:22:03.396-08:00

I hit a JVM crash happening in the Java 2D font manager code. Here's the stack trace at the crash point:Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)V [libjvm.so+0x298366]C [libfontmanager.so+0x59e4]C [libfreetype.so.6+0x73c9] FT_Stream_Close+0x19C [libfreetype.so.6+0xa065] FT_Stream_Free+0x25C [libfreetype.so.6+0xa6e2]C [libfreetype.so.6+0xaf78]

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-75312899476390403552008-12-31T17:42:00.000-08:002008-12-31T17:59:39.229-08:00

The Java 2D font renderer component was replaced when Sun JDK was open-sourced as OpenJDK with an open source version. But it appeared to have some bug. It's was about the vertical position gap in rendered fonts. I reported this bug on the OpenJDK mailing list and got a bug at:http://bugs.sun.com/view_bug.do?bug_id=6761856The results from the test (included in the bug page):Sun JDK: x=5.78125,y

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-9130446458995453902008-12-31T17:32:00.000-08:002009-12-29T22:43:57.997-08:00

AsyncGetCallTrace() is the unofficial interface for low overhead CPU profiling in the JVM. It allows CPU profilers to use a signal (SIGPROF) to collect samples of stack traces. Unlike many Java profiling tools out there that instruments bytecode, it has much lower runtime overhead. The problem was that it's a bit unstable and sometimes caused JVM crashes in OpenJDK6. So, I backported the

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-63597546028147216152008-12-31T17:04:00.000-08:002008-12-31T18:07:01.607-08:00

The jmap is a JVM memory inspection tool. "jmap -permstat pid" is the option to show the stats on the permgen (permanent generation) heap inside the JVM, where class metadata and interned strings are allocated.I happened to find a bug in jmap. In a small test, the "jmap -permstat" command reports only about 50-60% of the permgen memory usage (compared to the actual usage of permgen based on what

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-74307539690848566362008-07-25T22:16:00.000-07:002009-10-25T19:18:42.982-07:00

[This might be already out of date.]Here's how I build a 32 bit OpenJDK (build 31) on my Ubuntu 8.04 (Hardy Heron) system.1. DownloadDownload the following two filesthe source bundle,the binary plug which contains a small amount of the binary-only componentsfrom the download page, into the directory ~/openjdk7-ws/ and you get two files: the source bundle~/openjdk7-ws/openjdk-7-ea-src-b31-17_jul_

Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0