- Richmond JUG: Java and the Internet of Things
- Java 8 at EclipseCon 2014
- Java 8 Tour Kicks Off in Europe
- Java 8 Launch Webcast
- JavaOne 2014 Call for Papers Now Open!
- See Java in Action at SXSW
- Compete in the IoT Developer Challenge!
- Java EE 8 Community Survey: The Next Phase
- Vert.x: A Project to Watch
- Develop Java Applications Using a Raspberry Pi
Thursday Dec 19, 2013
Wednesday Aug 07, 2013
By Janice J. Heiss on Aug 07, 2013
by Monica Beckwith, Principal Member of Technical Staff at Oracle, and performance lead for the Java HotSpot VM's Garbage First Garbage Collector (G1 GC), shows how to adapt and tune the G1 GC for evaluation, analysis, and performance.
As Beckwith explains, the Garbage First Garbage Collector is the low-pause, server-style generational garbage collector for Java HotSpot VM. It uses both concurrent and parallel phases to achieve its target pause time and maintain good throughput. A garbage collector is a memory management tool. When G1 GC determines that a garbage collection is necessary, it first collects the regions with the least live data – known as garbage first.
Beckwith describes the collection phases and marking cycles, lists default tuning devices, offers recommendations about how to fine tune and evaluate garbage collection, and shows how to respond to overflow and exhausted log messages.
She concludes her article as follows:
“G1 GC is a regionalized, parallel-concurrent, incremental garbage collector that provides more predictable pauses compared to other HotSpot GCs. The incremental nature lets G1 GC work with larger heaps and still provide reasonable worst-case response times. The adaptive nature of G1 GC just needs a maximum soft-real time pause-time goal along-with the desired maximum and minimum size for the Java heap on the JVM command line.”
Check it out here.
Thursday Jan 24, 2013
By Janice J. Heiss on Jan 24, 2013
In a new article, now up on otn/java by yours truly, titled “Coding on Crete: An Interview with Java Specialist Heinz Kabutz,” noted Java commentator and consultant Dr. Heinz Kabutz shares insights about the Java platform and talks about his exotic life working as a developer on the island of Crete. Kabutz is well known as the author of the Java Specialists’ Newsletter which reaches some 70,000 developers worldwide.
In a previous 2007 interview, Kabutz lamented the large number of developers who do not engage in unit testing. He offered an update on this:
“The one place where unit testing is sorely lacking is with concurrent code. There are some tools that help find race conditions and deadlocks, but they typically find about a dozen faults per line of code. With such an amount of false positives, discovering a real problem is impossible.
Did you know that there is not a single—not even one—unit test for the Java Memory Model (JMM)? We have to just accept that it works on the Java Virtual Machine (JVM) we are running on. The theory is that if we write our Java code according to the JMM, the code will run correctly on any certified JVM. Unfortunately, the certification does not test the JMM thoroughly. Apparently, there are some tests for the java.util.concurrent classes, and so they assume that if these work, then the JMM must also be correct for that JVM.”
When asked about the greatest performance issues he remarked:
“The biggest performance issue today is still that we often cannot pinpoint the bottlenecks. Customers usually approach us with problems that they have not been able to solve, no matter how many man-months they've thrown at them. The most recent issue I looked at boiled down to a simple race condition. If two threads insert an entry into a shared HashMap at the same time, and the key's hash code points to the same entry in the table, then the HashMap can be corrupted and you might get two entries pointing to each other. This means that whenever you try to call contains() on the map, you risk getting an infinite loop.”
Check out the article.