Lone Star Software Symposium: Dallas - May 29 - 31, 2015 - No Fluff Just Stuff

Douglas Hawkins

Lone Star Software Symposium: Dallas

Dallas · May 29 - 31, 2015

You are viewing details from a past event
Douglas Hawkins

Lead Developer Java Performance Monitoring at Datadog

Douglas Hawkins has been passionately developing software for the past 20 years.
Throughout Doug's career, he has focused on creating performance intensive applications
in Java ranging from bioinformatics to financial exchanges.

After 10 years as a Java developer, Doug transitioned to working on Azul's Java Virtual Machine.
Today, Doug continues his interest in building performance tools for developers working on Datadog's Java Application Performance Monitoring.

While Doug's passion for developing software remains, his true passion is in sharing his
interest in low-level details and JVM performance with others.

Presentations

How (Not) To Measure and Profile Java Performance

Today, we all benefit from the sophistication of modern compilers and hardware, but that extra complexity can also make it difficult to reason about performance.

How a Compiler Works -- and Why It Matters to You

To write efficient SQL, you need to understand SQL execution plans. And to write efficient Java, you need to understand the JVM's execution plan.

Concurrency Concepts in Java

Unlike other languages, Java had a well-defined memory model from the very beginning, but over the years additional packages and low-level features have been added to make the most of today's hardware.

In this talk, we'll discuss concurrency in detail starting at the hardware up to Java's latest synchronization mechanisms and finally onto high-level concurrent collections.

Java Optimizations That Matter (and Some That Don't)

Early releases of Java performed poorly, but those issues largely disappeared long ago with the introduction of HotSpot. However, much of the performance advice for Java persists through hearsay from those early days.

JVM Mechanics

HotSpot promises to do wonders for us by Just-in-Time (JIT) compiling the “right” code for us, but how does it makes those decisions? And, perhaps more importantly, what happens when it's wrong?