oracle jdk vs ibm jdk
1,277 views
Skip to first unread message
sorin cristea
Jan 22, 2014, 1:28:17 PM1/22/14
to mechanica...@googlegroups.com
Hi all,
What is your opinion about to use ibm jdk instead of oracle(sun) jdk from the performance point of view. I know that ibm jdk has some differences against oracle jdk related to GC structure and heap memory.
Thanks
Sorin.
Jonathan Yu
Jan 22, 2014, 9:31:20 PM1/22/14
to mechanica...@googlegroups.com
Hi sorin,
Full disclosure: I work for IBM, though not on IBM's JVM (J9). This
post (and anything else on this list) are my own opinion.
I think the best way is to get both JVM's and benchmark against one
another. That's really the only way to know how well something
performs: write benchmarks specific to your application and test on
your own platforms of interest. Each also need to be tuned based on
what you're interested in - different compromises will yield different
results (e.g. if you're interested in latency vs throughput, for
example).
You can try to delegate that task to other folks, like the SPECjbb
benchmarks. But those workloads might not match yours, and so their
conclusions might not necessarily mean that things will run faster or
better in your environment with your particular workload.
Keep in mind that raw performance isn't the only thing that matters.
Associated tools (profilers, heap analyzers, etc) are also useful. I
know that IBM has its own heap dump format; Oracle has VisualVM for
HotSpot and Mission Control for its JRockit VM. These factors might be
more important than just being able to squeeze the most performance.
In theory, you should be able to develop/test with HotSpot and run on
J9 in production (or any of a number of other popular JVMs, including
Azul's Zing), if that happens to yield better performance for you.
That is, at least in theory, the beauty of a bytecode-specified
language like Java. On the other hand, you'll probably still have a
need for good tools. I'd humbly suggest looking at which of the
options provide you with the best developer experience, and only
change JVMs if you're finding that the JVM you're using doesn't suit
your needs (tooling, performance, other considerations). This is the
YAGNI (You Ain't Gonna Need It) principle.
One upside of HotSpot is that much of the code is open-sourced through
OpenJDK, so you can look through it.
Cheers,
Jonathan
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-symp...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Full disclosure: I work for IBM, though not on IBM's JVM (J9). This
post (and anything else on this list) are my own opinion.
I think the best way is to get both JVM's and benchmark against one
another. That's really the only way to know how well something
performs: write benchmarks specific to your application and test on
your own platforms of interest. Each also need to be tuned based on
what you're interested in - different compromises will yield different
results (e.g. if you're interested in latency vs throughput, for
example).
You can try to delegate that task to other folks, like the SPECjbb
benchmarks. But those workloads might not match yours, and so their
conclusions might not necessarily mean that things will run faster or
better in your environment with your particular workload.
Keep in mind that raw performance isn't the only thing that matters.
Associated tools (profilers, heap analyzers, etc) are also useful. I
know that IBM has its own heap dump format; Oracle has VisualVM for
HotSpot and Mission Control for its JRockit VM. These factors might be
more important than just being able to squeeze the most performance.
In theory, you should be able to develop/test with HotSpot and run on
J9 in production (or any of a number of other popular JVMs, including
Azul's Zing), if that happens to yield better performance for you.
That is, at least in theory, the beauty of a bytecode-specified
language like Java. On the other hand, you'll probably still have a
need for good tools. I'd humbly suggest looking at which of the
options provide you with the best developer experience, and only
change JVMs if you're finding that the JVM you're using doesn't suit
your needs (tooling, performance, other considerations). This is the
YAGNI (You Ain't Gonna Need It) principle.
One upside of HotSpot is that much of the code is open-sourced through
OpenJDK, so you can look through it.
Cheers,
Jonathan
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-symp...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
sorin cristea
Jan 23, 2014, 2:32:51 AM1/23/14
to mechanica...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages