Douglas Hawkins
Lone Star Software Symposium: Dallas
Dallas · May 17 - 19, 2013
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 as the
Lead Developer of 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
Introduction to Virtual Machines and Interpreters
Have you ever wondered what goes on inside the virtual machines and
interpreters that we use every day?
In this session, you'll see some of the inner workings of Python, PHP, Java, and JavaScript and learn that at the lowest level these languages really are not as different as they may seem.
Virtual Machines and Interpreters II: Inside the Java Virtual Machine
In part II of VMs and Interpreters, you'll dive into the inner workings of the Java Virtual Machines. You'll learn how your Java code is translated from Java source code to byte code and ultimately machine code.
You'll also see tools for viewing Java byte code and measuring performance changes caused by VM optimizations.
Understanding Garbage Collection
Most of us don't want to go back to the days of malloc and free, but the garbage collector isn't always our friend.
Understanding Concurrency
Unlike earlier languages, Java had a well-defined threading and memory model from its inception, and over the years additional packages have been added to the standard library to help solve concurrency problems.
Despite all this, Java's memory model still remains poorly understood and
its concurrency libraries under utilized.
Testing the Untestable
Often we avoid testing the most important things simply because they are hard to test,
but doing so runs the risk that these untested bits of code may fail at the worst
possible moment.
An Introduction to Redis
Redis may be the most misunderstood of the already highly misunderstood NoSQL
databases. This misunderstanding is a shame because Redis might also be the most
versatile and can work well in conjunction (not in replacement of) with a traditional
relational database.
Because hile nominally a key-value store, Redis is much more because each value can be a
document, a large bit field, a counter, a hash, a set, a sorted set, a list, or a queue.
This variety of data structures allows Redis to adapt to many different problems
including caching and queueing.