Thursday Sep 04, 2014

Interview with Nikita Salnikov-Tarnovski

Nikita Salnikov-Tarnovski is the co-founder of Plumbr, the memory leak detection product. Besides his daily technical tasks he is an active blogger, a JavaOne RockStar and a frequent conference speaker at Devoxx, JavaOne Russia, 33rd Degree, TopConf, JavaDay, GeekOut, Joker, and Jazoon.

Q: What are your JavaOne sessions about this year?

Salnikov-Tarnovski: My two talks are about identifying and solving memory leaks in applications, one conference session titled “keep memory leaks at bay” and one tutorial called “where is my memory.” Both sessions relate to how Java applications consume and use memory while running. I will discuss how to monitor your production environment; how to detect memory leaks and other memory inefficiencies; what to do if your application fails because of memory leak or becomes unbearable slow due to Garbage Collection taking too long, and so on.

Q: Are you giving tips and tricks during those sessions on how they can use Plumbr’s product?

Salnikov-Tarnovski: Last year, I talked about Java memory leaks and I used our product to present solutions. This year, I will talk about general methodology and techniques on how these problems can be detected and solved with the aid of the best tools on the market including our tool and any other freely available tools.

Q: Why are memory leaks important?

Salnikov-Tarnovski: Memory leaks are one of the top reasons why Java applications crash in production. Other memory related problems, such as inefficient Garbage Collection can make your application just stall for some arbitrarily long time. And your clients will be effected. E.g. when you hit the search button on and this all of a sudden takes too long, it is probably because GC kicked in and said: “Wait some 10 seconds, I will look for some garbage”.

Q: Aside from your sessions, what do you have planned for JavaOne?

Salnikov-Tarnovski: The main reason why I attend conferences - apart from talking about our product, of course – is to meet the many bright speakers and attendees. When you're a senior engineer with 12 years of experience, you want to go to conferences like JavaOne to meet your peers - people who are smarter than you- because you can learn a lot from them. You can discuss your problems and get feedback, and share your ‘war’ stories. This is the main reason why I attend conferences and I advise all my fellow engineers to go to JavaOne and other Java conferences. I'm planning to go to Java conferences as long as I am in this profession.

Learn more about Core Java sessions in the JavaOne content catalog

Wednesday Aug 07, 2013

Garbage First Garbage Collector Tuning

A new article, now up on otn/java, titled “Garbage First Garbage Collector Tuning,”
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 Feb 02, 2012

Java Champion Dick Wall on Genetics, the Java Posse, and Alternative Languages (Part One)

In Part One of a two-part interview, titled “Java Champion Dick Wall on Genetics, the Java Posse, and Alternative Languages (Part One),” Java Champion and Java Posse member Dick Wall explores the potential of genetic analysis to enhance human health, shares observations about alternative languages for the Java Virtual Machine (JVM), and reveals inside dope on the Java Posse. Wall admits to learning from Brian Goetz, Java language architect at Oracle, that pretty much everything he thought he knew about optimizing for the JVM was wrong, and discusses not only his current work using Scala to enhance our capacity to gain knowledge of our genetic vulnerabilities, but shares what he has learned about his own genetic challenges. In addition, he recounts some adventures with the Java Posse.

From the interview:

“…when I started working in Scala, I was worried that lots of extra immutable objects, which are created when you use immutable data often, would result in a lot more work for the garbage collector. After talking with Brian about it, I realized that, in fact, the opposite is often or usually true. Short-lived, immutable objects usually exist in a special part of the JVM’s memory referred to as Eden. Releasing the memory back to the pool from there is almost without cost. It is only longer-lived objects that get promoted to the JVM main heap that are expensive to garbage collect. So lots of small, short-lived objects can actually help the garbage collector out. There are other ways immutability can help or hurt performance, but ultimately, I decided to code for style and correctness first and worry about performance if and when it becomes an issue.”

Read the interview here.


Insider News from the Java Team at Oracle!



« March 2015