tag:blogger.com,1999:blog-75899419623504039802024-02-20T19:27:51.352-08:00Hiroshi YamauchiHiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.comBlogger24125tag:blogger.com,1999:blog-7589941962350403980.post-26820347469323060272013-09-03T20:38:00.000-07:002016-06-21T21:37:59.116-07:00OpenJDK at GoogleAt the JVM Language Summit 2013, Jeremy Manson gave a talk on some of the work we did around OpenJDK at Google:
Slides: http://www.oracle.com/technetwork/java/jvmls2013manson-2013920.pdf
Video: http://medianetwork.oracle.com/video/player/2630310903001
It covers some of my profiling and garbage collection work (on slides 29, 36 and 37):
- Making the stack trace Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-71523744038051430252013-08-29T21:49:00.000-07:002014-06-22T13:40:00.640-07:00Parallel initial mark (CMSParallelInitialMarkEnabled) and more-parallel remark (CMSEdenChunksRecordAlways) phases in the CMS garbage collectorThe Concurrent Mark Sweep (CMS) garbage collector in the Hotspot JVM has two stop-the-world pauses in its algorithm: the initial mark and the remark phases. The initial mark phase starts the concurrent mark process by marking the objects in the old generation that are directly (as opposed to transitively) reachable from the GC roots (such as local variables, static fields, and the objects in the Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-15622410550643617052013-06-21T21:48:00.000-07:002013-06-23T13:21:07.870-07:00Making the JVM release memoryIt's well known that a Java application (the JVM) won't typically release much memory once it's warmed up, even when the application is lightly loaded or even idle at a later time.
If you plot the memory usage (or the resident set size) of a Java application, it typically looks like a mostly flat line after an upslope at the beginning. At a low level, this corresponds to the memory pages of the Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com11tag:blogger.com,1999:blog-7589941962350403980.post-29939246419925463652012-10-19T17:47:00.000-07:002012-10-19T17:47:52.279-07:00The JVM continuation contributionAs described in the previous post, I gave a talk on an experiment that used JVM continuations for writing servers. I worked on a JVM continuation implementation based off the original continuation patch and used it for the experiment. I contributed the work back to the OpenJDK MLVM project as the following checked-in patches: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-21379076886317285482012-10-19T17:33:00.002-07:002012-10-19T17:33:19.707-07:00Talk: Continuations in serversOK. It happened two years ago. But, for the record, I gave a talk Continuations in Servers at the JVM Language Summit 2010.
It's about experimenting with a JVM-level continuation and allowing servers to be written like a synchronous server for better productivity, but with the low overhead of an asynchronous server for better scalability. These two types of servers differ in terms of Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0tag:blogger.com,1999:blog-7589941962350403980.post-35559480393515474262010-08-28T21:51:00.000-07:002010-08-29T00:56:52.915-07:00Fast unsigned byte lexicographical comparatorA 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, Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com1tag:blogger.com,1999:blog-7589941962350403980.post-424064763063235902010-06-26T22:33:00.000-07:002010-06-26T22:37:05.598-07:00Joined the OpenJDK Hotspot groupBack 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:00Short/Character.reverseBytes compiler intrinsicsI 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:00Shorter long multiplication in Server Compiler on x86 32 bitThe 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:00GC ThreadsThere 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:00Building OpenJDK fasterA 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:002014-07-28T15:52:55.175-07:00JVM process memoryHave 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:00More 2D bugfixesI 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:00A server compiler crash fixHere'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 crashHiroshi 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:00An event dispatch bug in JVMTII 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:00Java 2D Miter Line Join Decoration BugfixI'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.htmlHiroshi 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:00Multithreaded CMS crashI 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:00Mysterious int arrays in a heap dumpThis 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:00A server compiler crash during loop optimizationI 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:00JNI crashes in FontManager codeI 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:00Java 2D incompatibility between Sun JDK and OpenJDKThe 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,yHiroshi 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:00Stabilizing AsyncGetCallTraceAsyncGetCallTrace() 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:00Inaccurate permgen usage stats (jmap -permstat)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:00Building OpenJDK[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/Hiroshi Yamauchihttp://www.blogger.com/profile/10251146076703886326noreply@blogger.com0