Florian just won lot’s of hardware in a photography contest!
http://www.guru3d.com/article/a-decade-guru3d-photo-contest-winners/
Yay! 🙂
For more photos, see http://hirt-fotografie.ch/.
Florian just won lot’s of hardware in a photography contest!
http://www.guru3d.com/article/a-decade-guru3d-photo-contest-winners/
Yay! 🙂
For more photos, see http://hirt-fotografie.ch/.
Woho! First post from the bus! Yeah, well, I lost my drivers license due to speeding. Anyway, did my first code check-in from the bus just now. Constant access to the internet – yay! I’ll probably regret this. Well, at least Malin will regret me having this. 🙂
Here are a few links regarding new SPECjbb and SPECpower benchmarks with JRockit:
http://www.oracle.com/us/corporate/press/018046_EN
http://www.oracle.com/us/corporate/press/018045_EN
http://www.oracle.com/us/corporate/press/018043_EN
http://www.oracle.com/us/corporate/press/018044_EN
Yay!
I often get asked what I work with, and I’ve always had a hard time answering that. The problem usually starts when I introduce the concept of a Java Virtual Machine. So I thought I’d write a few lines on the evolution on computing to sort of explain how what I work with came about.
At the dawn of electrical computing programming was done by manually closing and opening electrical circuits. This evolved into punching holes into paper cards, representing the closed and open circuits. Eventually better methods of providing the instructions to the processing units came along, but at the hardware level the processing units still need to get its instructions as sequences of ones and zeroes. At first assemblers appeared that had simple mnemonics, or textual symbols, that were more or less a handy but direct representation of the sequences of ones and zeroes. Higher level programming languages, such as C, appeared that provided means of expressing the meaning of the program, the semantics, using better and easier to read syntax. Other programs, so called compilers, were responsible for analyzing the meaning of the program and translating it into machine code. As the processors became more advanced, so did the compilers, and today it is very complicated for a programmer to, even by hand, produce better and more efficient programs by hand in assembly, than the machine code produced by an optimizing compiler. Even with intimate knowledge of the processor architecture, it can be very hard to, for instance, decide upon the best way to schedule the instructions to best utilize parallel instruction pipes.
Java is a modern programming language, and represents another leap in abstraction. Its syntax is reminiscent to that of C, one of the most popular and successful imperative programming languages to date. Using a C-like syntax made the transition to Java easier for programmers already knowledgeable in C, and helped drive adoption.
Quite unlike C, however, Java programs are not compiled into machine code that the hardware which will execute the program can understand. Java programs are instead translated to platform independent byte code, which another piece of software, the Java Virtual Machine, or JVM, translates into machine code. You can view the Java Virtual Machine as a hardware abstraction layer, with its own machine code. The JVM does the final translation from the Java byte code to the machine code of the underlying hardware. Since the JVM is translating the Java byte code while it is running, the JVM has more information about the runtime characteristics of the program running in the JVM than a static compiler could ever have. This means that there is more information available to do advanced optimizations.
At the beginning, Java got a reputation for being very slow. The early JVMs were interpreting and translating the Java byte code line by line. This was rather inefficient. Today, high performance JVMs like JRockit are analyzing the semantics of the Java program while it is executing. It translates the program into machine code using a JIT (Just In Time) compiling strategy; translating method by method into machine code as it is required. It uses an internal profiler to find out how the application is executing, and dynamically does optimizations to the running program; in effect recompiling methods while the program is running. A modern JVM has a high performance, adaptive memory management system that efficiently handles the allocation and reclaiming of memory for the developer. Today, a Java program running in a modern JVM can outperform a well written C program.
So, to finally answer the question, I work with JRockit – one of the fastest and most advanced JVMs in the world.
Guess who’s on that list? 🙂
http://www.idg.se/2.1085/1.196558/det-danska-utvecklarundret
Of course, the credit is to the team, but it’s still fun!
There is now an Oracle JRockit fan page on facebook! Either search for Oracle JRockit among the pages or go to:
http://www.facebook.com/pages/Oracle-JRockit/41075602577
I just added logos and other graphics from the ancient Appeal days. Ahhh, the memories…
Yay! Now it’s finally done! Me and Malin are officially hitched. For some preliminary pictures, see the photo album. 🙂
The ceremony was beautiful, and the dinner was filled with wonderful and touching speeches. We’re truly blessed to have such wonderful friends and family.
Now we’re off to El Gouna, Egypt, for honey moon and diving. See y’all when we get back!
Sometimes it may seem hard to get a simple thread stack dump from your JRockit. You may for instance have started it using the -Xnohup (-Xrs) option, or as a service. I’ll list three different ways of looking at your threads in such situations.
The first way of getting your thread dump is to use jrcmd. My previous blog shows some basic jrcmd usage, so I’ll just mention the command name: print_threads. Basic usage is jrcmd <PID> print_threads, for example jrcmd 780 print_threads.
The second way is to simply start the management console on the JRockit you want to monitor. After connecting the console to the JVM and switching to the threads view, you should be looking at something similar to the screen shot below.
The third way is to use the MBean Browser’s capability to invoke arbitrary operations on MBeans (also described in the last blog). Go to the MBean Browser in the JRockit Management Console. Select the DiagnosticCommand MBean, and switch to the operations tab. Select the execute operation that takes a String argument and returns a String. Click the String button, and fill in the argument print_threads.
When you execute the operation you should see something like this:
There are also ways of doing this programmatically, for example by using the JRockit JMAPI, or by invoking the execute operation programmatically as described in another old blog.
Exception profiling is the business of finding out what exceptions are being thrown within your application and from where. In JRockit Mission Control you can find out how many exceptions have been thrown using JRA, and you can count the exceptions using the JRockit Management Console. Sadly there is no way of doing powerful exception profiling (i.e. looking at the stack traces for the exceptions, aggregating them and visualizing them directly in the JRockit Mission Control Client) just yet. This will be incorporated in a future version of Mission Control.
There is fortunately a way to do exception profiling with JRockit today. There are exception related verbose flags available in JRockit. These are examples on how to use them:
java -Xverbose:exceptions=debug …
java -Xverbose:exceptions=trace …
For a list of valid verbose options, please see http://e-docs.bea.com/jrockit/jrdocs/refman/optionX.html#wp999543.
Sometimes you really just want to enable this profiling for a little while, for example to avoid cluttering your log files. Then there is a nifty tool for JRockit called jrcmd you can use to turn on/off the exception profiling. It can be found under JROCKIT_HOME\bin\.
First use jrcmd to list all running java processes. Here is an example of what it may look like:
>jrcmd
10984 jrockit.tools.jrcmd.JrCmd
9396 C:\Java\eclipse3.3.1.1\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v200
70828.jar -data D:\Data\workspaces\workspace_3.3_facade -os win32 -ws win32 -arc
h x86 -showsplash -launcher C:\Java\eclipse3.3.1.1\eclipse.exe -name Eclipse –l
auncher.library C:\Java\eclipse3.3.1.1\plugins\org.eclipse.equinox.launcher.win3
2.win32.x86_1.0.2.R331_v20071019\eclipse_1021.dll -startup C:\Java\eclipse3.3.1.
1\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar -exitdata 1908_7
c -vm D:\jrockits\R27.4.0_R27.4.0-90_1.5.0\bin\javaw.exe -vmargs -Xms256m -Xmx51
2m -XgcPrio:deterministic -XpauseTarget:40 -Dosgi.bundlefile.limit=100 -jar C:\J
ava\eclipse3.3.1.1\plugins\org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar10976 Gegga
The numbers are the PIDs of the processes, and are used as the first argument to jrcmd to specify on what JRockit to address. You can use jrcmd to check what commands are available. Here is an example:
>jrcmd 10976 help
10976:
The following commands are available:
kill_rmp_server
start_rmp_server
kill_management_server
start_management_server
checkjrarecording
stopjrarecording
startjrarecording
print_object_summary
memleakserver
print_codegenlist
print_class_summary
run_optfile
dump_codelayout
dump_codelist
dump_codemap
print_utf8pool
print_properties
print_threads
datadump_request
runsystemgc
runfinalization
heap_diagnostics
oom_diagnostics
print_exceptions
version
timestamp
command_line
memprof
sanity
verbosity
set_filename
help
print_memusage
For more information about a specific command use ‘help <command>’.
Parameters to commands are optional unless otherwise stated.
Let’s get more information about the print_exceptions command:
>jrcmd 10976 help print_exceptions
10976:
Enable printing of Java exceptions thrown in the VM.
To turn exception printing off completely you need to set exceptions = false
even if it was turned on by stacktraces = true. NOTE: This handler is
deprecated. The preferred way of displaying exceptions is to use the
‘exceptions’ logging module: -Xverbose:exceptions.
Values for the parameters can be "true|all|false"
true – print all exception except java/util/EmptyStackException,
java/lang/ClassNotFoundException and
java/security/PrivilegedActionException
all – print all exception
false – don’t print exceptions
exceptions – print exceptions (string, false)
stacktraces – print stacktrace (string, false)
Never mind that it is using an old handler in R27.6. The functionality will be the same. Let’s enable the exception profiling:
>jrcmd 10976 print_exceptions stacktraces=true
If your application is throwing exceptions, you should now be seeing traces being logged to the console of that application. To turn off the exception logging, we do as the help suggests:
>jrcmd 10976 print_exceptions exceptions=false
Now, an even easier way to access the jrockit diagnostic commands is to use the JRockit Management Console. Simply connect the JRockit Management Console to the JRockit you wish to enable exception profiling on (from JRockit Mission Control). (Click the images to look at them in full size.)
Once the console is started, open the MBean Browser tab and move to the DiagnosticCommand MBean under bea.jrockit.management:
Double clicking on the ArrayList value of AllCommands will open up a list of all the available commands:
Now, select the operations tab and the executeDefault method that takes a String argument and press invoke. This will provide you with a dialog with push buttons for the arguments. In this case a single button with the label String. Press the String button and fill out the command. For example, print_exceptions stacktraces=true.
Press Ok on both of the dialogs and exception profiling should now be enabled. To turn it off again, just invoke the operation again and enter print_exceptions exceptions=false, analogously with how you would use jrcmd.
An even easier way for Oracle employees is to pick up a recent internal build of JRockit and use the Diagnostic Command tab in the JRockit Management Console. 🙂 Soon coming to a JRockit near you!
This year JRockit Mission Control will be represented at Oracle Open World! I’ll have one session and three hands-on labs.
The preliminary schedule is as follows:
Date: 2008-09-21
Hands-On Lab: Diagnostics with Oracle JRockit Mission Control
Session ID: S299540
Track: Oracle Develop: Java
Room: Golden Gate B2
Start Time: 13:15
Date: 2008-09-22
Hands-On Lab: Diagnostics with Oracle JRockit Mission Control
Session ID: S299540
Track: Oracle Develop: Java
Room: Golden Gate B2
Start Time: 16:00
Date: 2008-09-23
Nonintrusive Profiling and Diagnostics with Oracle JRockit Mission Control
Session ID: S299518
Track: Oracle Develop: Java
Room: Nob Hill AB
Start Time: 13:00
Hands-On Lab: Diagnostics with Oracle JRockit Mission Control
Session ID: S299540
Track: Oracle Develop: Java
Room: Golden Gate B2
Start Time: 16:00
I’m looking forward to seeing you there! 🙂