ivo's awfully random tech blog

Low-level Ruby observability APIs

Sat, 12 Jul 2025 00:00:00 +0100

When we need to understand what’s going on with our application, it’s common to (beyond using puts 😉) turn to observability tools: tools such as debuggers, profilers, and monitoring tools.

But have you ever wondered how they work? These tools often require access to Ruby internals that regular Ruby libraries or applications don’t have (or need). Language runtimes such as the CRuby VM (or the Java VM!) often put in limits on what applications can do, so as to ensure the memory safety, security and integrity of applications.

To support use-cases from observability tools, the CRuby VM has a number of low-level APIs that can be used to know more about such things as the state of threads, the global VM lock, object creation, garbage collection, etc. These APIs are:

include/ruby/debug.h: TracePoint, postponed job, frame-profiling, debug inspector APIs
include/ruby/thread.h: GVL instrumentation, thread specific storage APIs

These APIs are provided only to native extensions, and you usually need to write some C code to access them. That usually means a higher barrier of entry to start experimenting with them. And that’s not fun ;)

To fix that, I recently created (another!) Ruby gem, called lowlevel-toolkit. The objective of this gem, as the name suggests, is to both provide a toolbox of small observability tools that probably would be too small to release independently, as well as provide a starting point and living example to quickly get started in experimenting with Ruby observability APIs.

As of this writing, the gem provides the following tools, that each make use of the APIs listed above:

track_wants_gvl: Track when threads want to acquire the Global VM Lock
track_objects_created: Monitor object creation in your application
last_allocation_at: Get information about the last object allocation
on_gc_finish: Set up callbacks for when garbage collection finishes
who_called_me: Track the call stack of method invocations
release_gvl_profiler: Profile GVL release patterns

You can start using these tools today! Or, if you want to learn more and create your own tools, at the RubyKaigi 2025 conference I did a deep dive on each of these tools, and how the APIs they rely on work:

Slide deck:

Please do share what weird bugs you debugged and experiments you made with these APIs. I think the more people poking at these tools, the more we make it easier for everyone to understand what their Ruby apps are up to!

Talking Ruby GVL, Scheduling and Performance on the Dead Code podcast

Sun, 06 Jul 2025 00:00:00 +0100

I’m pretty happy that I got to go on the Dead Code podcast. In this episode, we discussed how the Ruby Global VM Lock (GVL) got to be and why it’s needed, went deep into scheduling — how to tweak how much time Ruby gives each thread; how M:N scheduling changes the behavior of threads in Ruby; and how Ruby may need a full scheduler and why.

We also discuss how tools such as gvl-tracing can be used to identify performance bugs (including in Ruby itself!), the direct-bind gem I recently created, and how it’s amazing people are starting to forget that Ruby is "supposed" to be slow and actually there’s been great progress in improving performance.

You can download the episode as an mp3 or listen to it online:

As always, feedback is welcome!

native-filenames: Find out where native methods are defined in Ruby

Sat, 05 Jul 2025 00:00:00 +0100

I’ve just released the first version of the native-filenames Ruby gem.

This gem can be used to probe where a native extension was defined. Here’s a quick example of how to use it:

[1] pry(main)> require 'native-filenames'

# Modern versions of bigdecimal use a native extension:
[2] pry(main)> require 'bigdecimal'
[3] pry(main)> NativeFilenames.filename_for(BigDecimal.singleton_class, :save_rounding_mode)
=> "/rvm/gems/ruby-3.4.4/gems/bigdecimal-3.2.2/lib/bigdecimal.so"

# Can also enquire about the standard library:
[4] pry(main)> NativeFilenames.filename_for(Array, :each)
=> "/rvm/rubies/ruby-3.4.4/bin/../lib/libruby.so.3.4"

# If something is written in Ruby, then you get an error:
[5] pry(main)> NativeFilenames.filename_for(Pry.singleton_class, :start)
RuntimeError: direct_bind_get_cfunc failed: method_entry is not a cfunc (RuntimeError)

I’ve just proposed to the Ruby core team that this behavior be incorporated in backtraces by default. (P.s.: This is now the behavior of the Datadog Ruby Profiler, starting with release 2.18.0.)

That is, given this example:

require 'bigdecimal'

BigDecimal.singleton_class.prepend(
  Module.new do
    def save_rounding_mode
      super
    end
  end
)

[:example].each do
  BigDecimal.save_rounding_mode do
    puts caller
    sleep 1
  end
end

you’d see this with Ruby 3.4:

native-filenames-example.rb:6:in 'BigDecimal.save_rounding_mode'
native-filenames-example.rb:6:in 'save_rounding_mode'
native-filenames-example.rb:12:in 'block in <main>'
native-filenames-example.rb:11:in 'Array#each'
native-filenames-example.rb:11:in '<main>'

but I’m hoping that in Ruby 3.5 it’ll become:

/rvm/gems/ruby-3.4.4/gems/bigdecimal-3.2.2/lib/bigdecimal.so:0:in 'BigDecimal.save_rounding_mode'
native-filenames-example.rb:6:in 'save_rounding_mode'
native-filenames-example.rb:12:in 'block in <main>'
/rvm/rubies/ruby-3.4.4/lib/libruby.so.3.4:0:in 'Array#each'
native-filenames-example.rb:11:in '<main>'

If you’re interested in the discussion, it’s up on https://bugs.ruby-lang.org/issues/21501. Feedback very welcome!

I wrote another weird ruby gem: direct-bind

Sun, 15 Jun 2025 00:00:00 +0100

I’ve written another weird Ruby gem: direct-bind.

It solves a very specific problem I keep running into. It’s oddly specific, so I may actually be alone in this ;)

As I find myself working on Ruby observability tools such as the profiler in the datadog gem, or the "show your Ruby threads in a timeline" gvl-tracing gem or the "build richer stack traces" backtracie gem I often mentally ask: Ok, so how do I get X piece of information from Ruby? Is there an API for it?

This thought often leads me to use tools such as readelf to check what functions Ruby exposes as public ("GLOBAL"):

$ readelf -sW libruby.so.3.4.4 | grep GLOBAL | grep "rb_thread_"
   341: 00000000002e5220    82 FUNC    GLOBAL DEFAULT   12 rb_thread_alone
   400: 00000000002e7540   475 FUNC    GLOBAL DEFAULT   12 rb_thread_sleep_deadly
   471: 00000000002e7ff0    11 FUNC    GLOBAL DEFAULT   12 rb_thread_io_blocking_region
   515: 00000000002ea870    56 FUNC    GLOBAL DEFAULT   12 rb_thread_stop
   559: 00000000002e1f00   140 FUNC    GLOBAL DEFAULT   12 rb_thread_lock_native_thread
   582: 00000000002e1cf0   101 FUNC    GLOBAL DEFAULT   12 rb_thread_prevent_fork
   650: 00000000002e5050   139 FUNC    GLOBAL DEFAULT   12 rb_thread_local_aref
   767: 00000000002ea830    25 FUNC    GLOBAL DEFAULT   12 rb_thread_run
   777: 00000000002ea7d0    84 FUNC    GLOBAL DEFAULT   12 rb_thread_schedule

...etc

and to spend a bunch of time reading the Ruby VM sources to find which functions exist and how I can access them.

But sometimes the function I need is right… there… but Ruby does not expose it as a public function ("LOCAL"):

$ readelf -sW libruby.so.3.4.4 |  grep "rb_thread_alive"
  5585: 00000000002db070    63 FUNC    LOCAL  DEFAULT   12 rb_thread_alive_p

Often, many of these functions are bound to ruby methods (from Ruby’s thread.c):

/*
 *  call-seq:
 *     thr.alive?   -> true or false
 *
 *  Returns +true+ if +thr+ is running or sleeping.
 *
 *     thr = Thread.new { }
 *     thr.join                #=> #<Thread:0x401b3fb0 dead>
 *     Thread.current.alive?   #=> true
 *     thr.alive?              #=> false
 *
 *  See also #stop? and #status.
 */

static VALUE
rb_thread_alive_p(VALUE thread)
{
    return RBOOL(!thread_finished(rb_thread_ptr(thread)));
}


void
Init_Thread(void)
{
    // ...
    rb_define_method(rb_cThread, "alive?", rb_thread_alive_p, 0);
    // ...
}

The only way of calling these functions is to ask Ruby to call the Thread#alive? method on a given thread object, as you would to in regular Ruby code.

But… the kind of tools I work on often need to call into the Ruby VM at "inconvenient" times: during a garbage collection cycle; or when a thread does not have the Global VM Lock. In those situations, it’s not possible to ask Ruby to call methods.

For instance, recently I was working on a feature for the gvl-tracing gem where I needed to know if the current thread was still alive, or if it was in the process of terminating. And well, if you try to call Thread#alive? in the middle of a thread terminating, you’ll trigger a crash because Ruby has already cleaned up some of the thread’s state that makes it able to call Ruby methods.

So again in I went into the Ruby VM source code, and found another solution which almost almost worked: checking if the current fiber was alive. There’s a public API for that! But… Ruby allocates fiber objects lazily, so if the fiber object didn’t exist then… hey here I am crashing the VM because the fiber object can’t be allocated if a thread is terminating.

And all the while that rb_thread_alive_p is exactly what I wanted! So I decided to experiment with something that’s been gnawing at me for a long time — is it possible, and how hard is it to get the pointer to rb_thread_alive_p that rb_define_method received back from Ruby?

The long answer to that question is that it is possible, and not that hard. The short answer is direct-bind ;)

The direct-bind gem takes heavy inspiration from some experiments we’ve done at Datadog, that I also recently discovered is what the debug gem basically does. There’s two key insights to doing what we need: The data we want to get access to lives on the Ruby object heap, and so it’s possible to use the "iterate every object" API rb_objspace_each_objects to locate the objects we want; and the layout of the data structure itself is quite simple, flat, and has not changed (for the purposes of direct-bind) in a long time.

With some C coding, here’s how the resulting API looks:

VALUE (*is_thread_alive)(VALUE thread);

is_thread_alive = direct_bind_get_cfunc_with_arity(rb_cThread, rb_intern("alive?"), 0, true).func;

is_thread_alive(rb_thread_current());

And that’s it! Suddenly I was able to solve my problem of calling into rb_thread_alive_p, even though it’s not a public Ruby API directly available for extensions to use.

Because the specific part of the structure where we’re getting this info from hasn’t changed in a long time, direct-bind works for Ruby 2.5 and above, including current Ruby 3.5 master. (It probably would work on older Rubies but… I leave that as an experiment for someone else.)

So… that’s it! direct-bind is out there in the world, I’m not sure if anyone else other than me is ever going to want to do something like this, but yeah, it was a fun hack!

M:N scheduling and how the (Ruby) global vm lock impacts app performance

Sun, 30 Mar 2025 00:00:00 +0000

A while back I created the gvl-tracing gem as an experiment to help understand what was going on inside Ruby when multiple threads are in use.

But Ruby is not standing still! Ruby 3.3 saw the introduction of M:N scheduling (off by default) which is a feature I’ve been quite looking forward to. What is M:N scheduling, you ask? It’s a new execution strategy for Ruby threads that is similar/borrows from to the one used by Java’s virtual threads, Go’s coroutines or Erlang’s processes. (Note that when I say it’s similar to other VMs, I’m comparing the execution strategy part of the implementation, not the APIs or features provided).

With M:N scheduling Ruby threads are no longer mapped 1:1 to operating system threads; instead any M Ruby threads you choose to create are mapped to a pool of N operating system threads that Ruby automatically manages for you. Up until now, Ruby used a 1:1 strategy; now M will usually not be the same as N, and this is where the name comes from.

Why is this cool? For two big reasons: it makes Ruby threads into a simpler programming model, and it provides improved performance. Starting with performance, operating system threads are costly to create and manage, which is where the typical guidance for not creating too many, and to use techniques such as pooling comes from. With the introduction of ractors, this became an even bigger bottleneck for Ruby: without M:N scheduling each ractor would require at least one (new) thread, which put a clear limit on not using too many ractors.

By decoupling Ruby threads from operating system threads, code using threads or ractors becomes a lot more scalable! This is actually quite similar to how when you use fibers your application can do a lot more with less.

The second benefit from M:N scheduling is how it simplifies the programming model: Once creating threads and ractors becomes extremely cheap, you no longer need to pool them or reuse them or treat them as very special expensive snowflakes. Instead, they become a lot closer to fibers, where in many cases you can create almost as many as you need and not think too much about it.

This brings us back to talking about the GVL for two reasons: 1. If you’re not using ractors, only threads, then even with M:N scheduling you’ll still only have one Ruby thread running at a time, regardless of how that gets mapped to operating system threads; and 2. How to visualize the impact of M:N scheduling on your app?

At RubyConf 2024 I explored this topic and introduced a novel feature for the gvl-tracing gem: the ability to show both what the Ruby threads were doing (the M part) as well as how the Ruby VM was mapping them into operating system threads (the N part).

And, while I thought this new feature may be quite interesting by itself, I was quite surprised to uncover two different Ruby VM bugs related to the M:N scheduler (fixes are work in progress as of this writing: 1, 2).

You’ll find the video and slides for my RubyConf 2024 talk below.

Slide deck:

And that’s not all! An additional element was added to this story with Ruby 3.4: it introduces RUBY_THREAD_TIMESLICE, a setting to control how long each Ruby thread gets to run before being switched. I’m hoping this will lead Ruby’s default of 100ms to be progressively lowered, hopefully to something close to 10ms (which is what Python uses 😉).

Although, in the medium/long term, and connected to the M:N scheduling changes, what I believe will unlock the next wave of great performance in the presence of multiple threads, ractors and fibers is for Ruby to introduce a full scheduler, similar to the one used inside the operating system. Such a scheduler would allow Ruby to better balance IO-heavy work with CPU-heavy work, and make sure that all parts of the application get to run timely and with a fair distribution of resources. This is especially relevant as the more Ruby does internally, the less the operating system’s scheduler can help out with.

In the future, I hope to explore more around this topic of a Ruby scheduler.

Building an always-on (Ruby) production profiler

Wed, 19 Mar 2025 00:00:00 +0000

For the past few years, I’ve been working at Datadog on a new open-source Ruby profiler. This profiler is shipped as part of the datadog Ruby gem.

Why spend all this time and effort on building a new profiler? The key detail is that we want (and need) something that is built to be always-on in production. That translates to having really low overhead in several dimensions, including low cpu usage, low memory usage and low impact on the application’s latency, while also being something that can run for a long time unattended without impacting the application.

Doing this involves a different set of trade-offs than most profilers. For instance, the datadog profiler is able to profile cpu, wall-time, allocations, heap, the Global VM Lock, and Garbage Collection all at the same time, and while staying within the same low-overhead. It also has workarounds for a number of bugs in Ruby and 3rd-party gems, so as to make sure it never impacts any application it is added to.

I’ve had to spent quite a lot of time writing C and Rust to make the Datadog Ruby profiler happen. And it even spawned a few off-shoots I’ve talked about in this blog in the past, such as the gvl-tracing gem to investigate activity around Ruby’s Global VM Lock and the backtracie gem to read stack traces with more detail and lower overhead.

Last year, at the RubyKaigi 2024 conference I had the chance to talk about how Datadog’s Ruby profiler works. It took me almost a year to write this blog post, but here’s the video and slide deck for the talk.

Slide deck:

Ruby performance is seeing a big renaissance: YJIT is getting better and better, JRuby and TruffleRuby continue to provide really strong alternatives, there’s a number of new profilers for Ruby beyond the Datadog profiler (Vernier, pf2), and there’s ongoing work to upgrade Ruby’s garbage collector.

And… I am totally here for it!

Backtracie and the quest for prettier Ruby backtraces

Thu, 07 Mar 2024 00:00:00 +0000

A backtrace is one of those Ruby features that is extremely useful, but we never think about it. They’re just always there in our time of need — be it when an error happens, when exploring our code inside a irb or a debugger, or even when profiling our app.

For a while now, I’ve been thinking about, and working on, possible improvements for Ruby’s backtraces — I’ve blogged about it [1, 2], and even ended up creating the backtracie Ruby gem to be able to make those improvements a reality.

Recently, at FOSDEM 2024, I had a chance to talk about how Ruby backtraces work inside the Ruby VM, as well as how backtracie works. If you’ve ever been curious about how this mechanism works, this talk is for you.

Slide deck:

Also, during the talk, I mentioned that adding class names to Ruby backtraces was being discussed for integration into Ruby itself and I’m very happy to announce that the feature was recently approved by Matz, the creator of Ruby:

…so look forward to it in Ruby 3.4! It’s really cool to have been part of this effort :)

P.s.: If you’ve not heard before of FOSDEM, I really recommend taking a look. This yearly conference is free (you don’t even need to register), and you get such an amazing amount of talks about every subject in free software. I’ve been attending it yearly, and hope to come back next year as well.

Look out! Gotchas of using threads in Ruby

Mon, 04 Mar 2024 00:00:00 +0000

Threads (along with fibers and ractors) are all extremely powerful and useful tools for Ruby developers. Yet, they often seem to be surrounded by this aura of mystery, as if they are something for wizards to employ in their magicks and not for mere mortals to make use of.

I recently spoke at EuRuKo 2023 about this topic with the aim of demystifying Ruby threads. You can find the video and slides for my "Look out! Gotchas of using threads in Ruby" talk below.

By documenting common gotchas, and then explaining why they happen and how to fix them, let’s build a better mental model of how the Ruby concurrency primitives work, and hopefully get confident and excited about using them safely 😉

Slide deck:

Understanding the Ruby Global VM Lock by observing it

Sun, 23 Jul 2023 00:00:00 +0100

The Global VM Lock (GVL), also known as Global Interpreter Lock (GIL), is an implementation detail of the Ruby VM. At a high-level, it prevents Ruby code across multiple threads from running in parallel (while still allowing concurrency!).

The GVL is an extremely important implementation detail, as it can have a big impact on the performance and responsiveness of any Ruby application that uses more than a single thread to do its work.

I’ve previously blogged (see bottom of the post for links!) about my ongoing experiments building the gvl-tracing gem to try to learn more about how the GVL works, and how it impacts Ruby apps.

Recently, I had the incredible opportunity to present what I’ve learned so far at the RubyKaigi 2023 conference.

You can find the video and slides for this talk below, and here’s a live link to all the experiments, including code and perfetto links.

Slide deck:

Ruby's unexpected I/O vs CPU unfairness

Sat, 11 Feb 2023 00:00:00 +0000

Recently, while benchmarking a test application, I observed that if I mixed threads doing input/output (such as reading files or network/database requests) and threads doing CPU work, the I/O work would be slowed down massively. It took me a while to realize this was caused by how (and when) Ruby switches between threads.

For instance consider querying a web server (here I’m using google as an example) as fast as possible:

require 'net/http'
require 'benchmark/ips'

def perform_request
  Net::HTTP.start('www.google.com', open_timeout: 0.5, read_timeout: 0.5, write_timeout: 0.5) do |http|
    http.get('/')
  end
end

Benchmark.ips do |x|
  x.config(time: 1, warmup: 0)
  x.report("request") { perform_request }
end

When I run this example on my current wifi, I get:

$ bundle exec ruby io-cpu-unfairness-1.rb
Calculating -------------------------------------
             request     16.571  (±12.1%) i/s -     17.000  in   1.039825s

I get an OK-ish 60ms per request, which means I do a little over 16 such requests in a second.

Now, what happens if I add a background thread that is crunching some data while I’m trying to reach out to google?

require 'net/http'
require 'benchmark/ips'

Thread.new do
  Thread.current.name = 'cpu-heavy'
  foo = 0
  while true
    foo += 1
    foo = 0 if foo > 1_000_000_000_000
  end
end

def perform_request
  Net::HTTP.start('www.google.com', open_timeout: 0.5, read_timeout: 0.5, write_timeout: 0.5) do |http|
    http.get('/')
  end
end

Benchmark.ips do |x|
  x.config(time: 1, warmup: 0)
  x.report("request") { perform_request }
end

$ bundle exec ruby io-cpu-unfairness-2.rb
Calculating -------------------------------------
             request      1.664  (± 0.0%) i/s -      2.000  in   1.201622s

Suddenly, performance takes a big dive and we don’t even get through more than a single request per second.

What’s going on here?

Using the gvl-tracing gem (on Ruby 3.2), we can actually visualize what’s happening.

Compare the thread timelines for both examples:

Figure 1: Timeline for fast example.

Figure 2: Timeline for slow example (with a background thread consuming CPU).

This is in fact caused by Ruby’s Global VM Lock (GVL), and the way Ruby decides when to switch between several threads. Whenever a thread is going to block waiting for some reply, and there are other threads wanting to run, Ruby will switch to them. But if a thread never blocks, then Ruby will give it around 100ms to run before forcing a switch.

This explains the difference between figures 1 and 2: In figure 1, the "network requests" thread spends most of its time waiting on network requests, and if we zoom in (figure 3, below), we see that when a reply is available, the thread immediately wakes up and issues the next network request.

Figure 3: Zooming in on the fast example.

In the figure 2, the "network requests" thread spends most of its time in the ready state — that is, it’s ready to continue working, but it must wait for the cpu-heavy thread to finish its own 100ms.

This behavior ends up being quite unfair for a thread doing I/O work. That thread may only work for a few milliseconds before blocking, but once it blocks it must wait for all other threads to have their own go, which at 100ms per thread can take a long time.

The takeaway here is, be careful when mixing input/output (such as reading files or network/database requests) and CPU work: suddenly your I/O will be slower and it may be hard to understand why. This can happen if you’re using a multi-threaded webserver, such as puma, or a multi-threaded job queue such as sidekiq.

Edit: If you know that some block of Ruby code will be CPU intensive, then as @maciejmensfeld suggested, you can use Thread#pass to tell the Ruby scheduler to give other threads a chance before the 100ms period is up.

Talking Ruby Performance Tooling at the Ruby Rogues podcast

Tue, 24 Jan 2023 00:00:00 +0000

I was recently invited to the Ruby Rogues podcast for a second time. We talked about the pitfalls of Ruby performance, when and why you should profile, and the tools I’ve been working on to better explore and optimize Ruby performance.

These include:

You can download the episode as an mp3 or listen to it online at https://topenddevs.com/podcasts/ruby-rogues/optimizing-ruby-user-experience-with-ivo-anjo-ruby-574.

Hope you find it useful!

P.s.: This blog is now brought to you by Ruby 3.2 with YJIT ;)

Ruby reuses native OS threads after Ruby Threads die

Sat, 26 Nov 2022 00:00:00 +0000

Since Ruby 1.9, each Ruby Thread gets executed on its own native operating system thread.

But, as a performance optimization, Ruby will try to reuse native operating system threads if it can.

When a Ruby Thread terminates, Ruby will not immediately terminate the operating system thread that was hosting it. Instead, it will keep it around for a few seconds, and if in that time period the application starts a new Thread, then Ruby will reuse an existing operating system thread.

This can be observed on Ruby 3.1+ by using the new Thread#native_thread_id method:

puts RUBY_DESCRIPTION

def thread_info
  "Thread #{Thread.current} is being hosted by #{Thread.current.native_thread_id}"
end

puts Thread.new { thread_info }.value
puts Thread.new { thread_info }.value
puts Thread.new { thread_info }.value

puts "Sleeping for a bit..."
sleep 10

puts Thread.new { thread_info }.value

…and here’s the result of running this example:

ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]
Thread #<Thread:0x00007f0e5e985030 example1.rb:7 run> is being hosted by 44061
Thread #<Thread:0x00007f0e5e9841a8 example1.rb:8 run> is being hosted by 44061
Thread #<Thread:0x00007f0e5e98bcc8 example1.rb:9 run> is being hosted by 44061
Sleeping for a bit...
Thread #<Thread:0x00007f0e5e98b070 example1.rb:14 run> is being hosted by 44084

On older Rubies, Thread#native_thread_id did not not exist yet, but we can implement our own:

puts RUBY_DESCRIPTION

# Only for Linux; supporting other OS's is left as an exercise for the reader ;)
def current_native_thread_id
  File.readlink("/proc/thread-self").split("/").last
end

def thread_info
  "Thread #{Thread.current} is being hosted by #{current_native_thread_id}"
end

puts Thread.new { thread_info }.value
puts Thread.new { thread_info }.value
puts Thread.new { thread_info }.value

puts "Sleeping for a bit..."
sleep 10

puts Thread.new { thread_info }.value

…and here’s the result of running this example on the older Ruby 2.7 series:

ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]
Thread #<Thread:0x0000564a32b02110 example2.rb:12 run> is being hosted by 45998
Thread #<Thread:0x0000564a32afbdb0 example2.rb:13 run> is being hosted by 45998
Thread #<Thread:0x0000564a32af9f38 example2.rb:14 run> is being hosted by 45998
Sleeping for a bit...
Thread #<Thread:0x0000564a32af7e90 example2.rb:19 run> is being hosted by 46002

I hope you found this Ruby tidbit interesting!

Hunting production memory leaks at RubyKaigi 2022

Wed, 09 Nov 2022 00:00:00 +0000

Existing Ruby tooling is quite helpful when investigating memory leaks if and when we can reproduce them on our development machine or staging environment. But what about those cases when the memory leak only really shows up in Production? Perhaps over a long time period?

Me and @KJ Tsanaktsidis recently presented a talk at RubyKaigi 2022 about two new Ruby gems — ruby_memprofiler_pprof and backtracie.

Together, they can be used to provide low-overhead heap sampling, enabling the investigation of Ruby memory leaks in production.

You can find the video and slides for the talk below! And as always, feedback is very welcome!

Slide deck:

Tracing Ruby's (Global) VM Lock

Sun, 17 Jul 2022 00:00:00 +0100

(🇯🇵 Japanese translation thanks to @hachi8833)
(🇰🇷 Korean translation thanks to @heka1024)

I recently created a new Ruby gem: the gvl-tracing gem. This gem can be used to generate a visualization of what your Ruby threads are up to:

Click Open Example 1 to explore this example. Alternatively, download example1.json.gz and open it with the Perfetto UI. Example code is from example1.rb.

Interested? Read on for details and how to generate your own traces.

what is the global vm lock?

The Ruby VM is a big program mainly written in the C programming language (we’ll leave JRuby and TruffleRuby for another day 😁).

When you create threads in your Ruby application, the Ruby VM actually matches them, one to one, to operating system threads. (There’s been some discussion on changing this at some point, which would be really interesting!)

Thus, the Ruby VM a big multi-threaded C program. In such programs, to avoid concurrency bugs, you need to adopt a strategy to ensure correctness when multiple threads are working at the same time. The Ruby developers adopted a strategy that they chose to call the Global VM Lock, or GVL for short.

(As an aside, you may have heard the GVL instead being called the Global Interpreter Lock, or GIL. This term comes from the Python community; the Python interpreter uses something very similar to the GVL, for similar reasons. The Python developers just named it differently.)

The concept of the GVL is that whenever any thread is running Ruby code or otherwise needs to interact with Ruby VM structures, that thread needs to be holding the GVL, and no other thread can be doing the same. This ensures the correctness of the Ruby VM by making sure threads are not modifying objects and other critical VM structures at the same time.

As a consequence of the GVL, at the level of our own Ruby code in our Ruby applications, we can observe concurrency (multiple Ruby threads can be working on multiple things at a time), but not parallelism (at any one time, only one Ruby thread is making progress).

actually, the global vm lock is no more!

One of the big features of the Ruby 3.0 release is the introduction of Ractors. Ractors are a new concurrency primitive that was introduced to both the language and VM (and that I experimented with in other posts, see 1 and 2).

A key refactoring that was done when Ractors were introduced was making the Ruby VM go from having a single Global VM Lock to having multiple Global VM Locks, one per Ractor.

Now you may have spotted that naming something Global but then having multiple of them is probably slightly confusing, and the Ruby core developers agree with you: They actually don’t call it the Global VM Lock anymore. Since https://github.com/ruby/ruby/pull/5814, they just call it thread_sched.

But, if your Ruby application is not using Ractors — which I would bet is still the case for most applications — then, for all intents and purposes, you still are at the mercy of a single thread_sched, which acts exactly as the GVL did prior to Ruby 3.

Having gone through all that introduction, let’s move on to the fun parts!

let’s talk gvl tracing

Recently, @_byroot (Jean Boussier) introduced an amazing new Ruby VM feature that gives users access to the state of the GVL. He called it the GVL Instrumentation API, and with it we can observe in detail what is happening with the GVL: when threads grab it, when they release it, how long they hold on to it, and how long other threads spend waiting for it.

Update, 2023: I feel awful that I failed to notice that the GVL Instrumentation API PR stated that the feature was co-authored by @eightbitraptor (Matt Valentine-House) and I had originally omitted this detail. Big thanks to Matt as well! 🙇

Ever since I learned of this new VM API I knew what I wanted to use it for: I wanted to build a visual timeline showing all this information.

Thus the gvl-tracing gem was born.

And here’s how it looks for a very simple Ruby application:

You can play with this example yourself by clicking Open Example 2. Alternatively, download example2.json.gz and open it with the Perfetto UI. Example code is from example2.rb.

So, what are we looking at here? We’re looking at this Ruby code:

require "gvl-tracing"

def fib(n)
  return n if n <= 1
  fib(n - 1) + fib(n - 2)
end

GvlTracing.start("example2.json")

other_thread = Thread.new { fib(37) } # runs in other thread
fib(37) # runs in main thread

other_thread.join
GvlTracing.stop

In this app, two threads are competing for the GVL, and you can see how Ruby gives each of them 100ms to run at a time, before pausing and switching to the next one. The thread executing at any point is the one in the resumed state; the other thread remains in the ready state, meaning it has work to do, it’s just waiting for its next turn holding the GVL.

You can observe how in Ruby you usually get concurrency, but not parallelism: both threads have plenty of work to do, but they take turns executing, which makes them both take longer.

If you add more threads you can start to see longer and longer gaps between when any given thread actually gets its turn. Here’s the same example I presented at the beginning of this post reproduced again: with 3 threads competing for the GVL, each thread needs to wait for 200ms for each 100ms spent working.

How would this application look if it was changed to use two different Ractors? As you may have suspected, you get real parallelism, with threads inside different Ractors acting independently:

You can play with this example yourself by clicking Open Example 3. Alternatively, download example3.json.gz and open it with the Perfetto UI. Example code is from example3.rb.

Yay, we established that ractors work! Both threads, each belonging to a different Ractor, run in parallel, unimpeded by the other.

using gvl-tracing: you need ruby 3.2+

Ruby 3.2 was released in December 2022 and includes the GVL Instrumentation API. Ruby 3.3 and other future versions will also work as well!

using gvl-tracing: how to try it on your own applications

The gvl-tracing gem provides only provides two apis: start and stop.

Use start with a file name to start recording data: GvlTracing.start('my-test-trace.json').
Use stop to finish the recording: GvlTracing.stop().

You can browse the resulting tracing file by loading it into the Perfetto UI.

We’re still at the very beginning of exploring gvl tracing and what we can learn about the Ruby internals with it.

Find something interesting? Consider dropping it on a GitHub gist and sharing the link! I’m @KnuX on twitter, and feel free to reach out via e-mail as well.

Finally, I’d like to thank @_byroot (Jean Boussier) for the awesome new API, and I also recommend you check out Shopify’s gvltools gem, which provides other ways of measuring the impact of the GVL on your own applications.

Talking Ruby Ractors and Concurrency at the Ruby Rogues podcast

Sat, 22 Jan 2022 00:00:00 +0000

I was recently invited to the Ruby Rogues podcast to talk about Ractors (the new Ruby concurrency primitive added in Ruby 3), as well as Ruby concurrency in general.

You can download the episode as an mp3 or listen to it online at https://topenddevs.com/podcasts/ruby-rogues/ractors-ft-ivo-anjo-ruby-527.

As usual, all feedback is welcome! Get in touch if you’d like to talk about Ractors and Ruby concurrency — I can literally talk for hours about it :)

The unexpected cost of Ruby's NoMethodError exception

Mon, 01 Nov 2021 00:00:00 +0000

💡	A fix for this performance gotcha has been merged for Ruby 3.3! See https://github.com/ruby/ruby/pull/6950 and https://bugs.ruby-lang.org/issues/18285 for details!

The NoMethodError exception is how Ruby signals that the code tried to call a method that does not exist.

class Example
end

Example.new.foo
# => NoMethodError: undefined method `foo' for #<Example:0x00005636879ce398>

Now, raising and rescuing exceptions is known to be slow (due to, among other things, expensive stack trace generation) and thus it’s pretty common knowledge that you should avoid having triggering too many of them in your production code.

But… have you ever considered that after you rescue an exception, getting or printing the message from it may be expensive as well?

In particular, the message from a NoMethodError can be much costlier than for other Ruby exceptions. Consider the following example:

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'

  gem 'benchmark-ips'
end

puts RUBY_DESCRIPTION

class GemInformation
  # ...

  def get_no_method_error
    method_does_not_exist
  rescue => e
    e
  end

  def get_runtime_error
    raise 'Another Error'
  rescue => e
    e
  end
end

NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error
RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error

Benchmark.ips do |x|
  x.config(:time => 5, :warmup => 2)

  x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message }
  x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message }

  x.compare!
end

…now let’s run it:

ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux]

no method error message cost
                        180.215k (±14.4%) i/s -    885.250k in   5.015251s
runtime error message cost
                          6.806M (± 1.8%) i/s -     34.324M in   5.045347s

Comparison:
runtime error message cost:  6805678.3 i/s
no method error message cost:   180214.6 i/s - 37.76x  (± 0.00) slower

On my machine, getting the message from a NoMethodError is 37 times slower than from a regular RuntimeException in this example.

But wait, it gets worse! A common pattern in Ruby is to implement an inspect method that prints extra information for debugging. Let’s see what happens to the benchmark when we augment our Example class with one such method:

class GemInformation
  # ...

  def get_no_method_error
    method_does_not_exist
  rescue => e
    e
  end

  def get_runtime_error
    raise 'Another Error'
  rescue => e
    e
  end

  # <-- We added this!
  def inspect
    Gem::Specification._all.inspect
  end
end

…and the benchmark result:

ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux]

no method error message cost
                        115.390  (± 1.7%) i/s -    580.000  in   5.027822s
runtime error message cost
                          6.938M (± 0.5%) i/s -     35.334M in   5.092617s

Comparison:
runtime error message cost:  6938381.6 i/s
no method error message cost:      115.4 i/s - 60130.02x  (± 0.00) slower

Yes, you read that well. Printing the message of a NoMethodError just got 60130 times slower.

TL;DR today I learned that while getting the message from a NoMethodError exception, Ruby will call inspect on the object that was missing the method.

This means that for instance, if your method has a very costly inspect (because you really only thought it was going to be called during development), you may have a bad time. For instance, if your object is a Rails controller, or a similar object that holds and prints many references when being debugged.

We can confirm this with another small example:

class Example
  def inspect
    puts '#inspect got called'
  end
end

begin
  Example.new.foo
rescue => e
  puts 'Error message is:'
  puts "#{e.message}"
end

…and its output:

Error message is:
#inspect got called
undefined method `foo' for :Example

Sunday Lol: Embedding images in commit logs

Sun, 14 Mar 2021 00:00:00 +0000

Recently, I discovered the notcurses library, the latest in a long line of weird ways of abusing a terminal emulator.

It provides a tool called ncplayer which can be used to preview images and videos from the terminal.

And then — I decided to see if I could pipe its result into git, and turn it into a commit message. Turns out that it works!

(P.s.: You’ll need a recent version of ncplayer)

Of course, this is an awful thing: it won’t work outside a terminal (definitely will not show up correctly on GitHub), it probably will break on different kinds of terminals, etc. So, just a curiosity :)

Ruby Ractor Experiments: Safe async communication

Sun, 14 Feb 2021 00:00:00 +0000

(This post is also available in 🇯🇵 Japanese thanks to @hachi8833.)

Ractors (api documentation, design documentation) are a new concurrency abstraction for Ruby 3.0 inspired on the actor model.

From the point of view of a Ractor that wants to send some information to another, communication can either be:

asynchrous (or non-blocking): a Ractor can send information to another using Ractor#send, placing it into an infinite queue that can be read by the destination Ractor with Ractor.receive
synchronous (or blocking): a Ractor can use Ractor.yield to block until another Ractor calls Ractor#take

Let’s consider the async case: Let’s say we want to send information to another Ractor, but don’t want to block for it to finish processing it. What happens if the receiving Ractor is too slow to process the data?

receiver_ractor = Ractor.new do
  loop do
    message = Ractor.receive
    sleep 1
    puts "Processed #{message}"
  end
end

counter = 0
while true
  counter += 1
  receiver_ractor.send(counter)
end

As expected, if the receiver cannot keep up with the sender, more and more memory will be used, until the system memory is exhausted and the application crashes.

Looking at the Ractor API, there’s no built-in way for the sender to check if the receiver is falling behind or not, so I came up with the following approach:

receiver_ractor = Ractor.new do
  processing_queue = Queue.new

  Thread.new do
    sleep(1) # simulate a slow start for this thread

    loop do
      message = processing_queue.pop
      puts "Processed from queue: #{message}"
    end
  end

  loop do
    queue_size = processing_queue.size
    sender, message = Ractor.select(Ractor.current, yield_value: queue_size)

    if sender != :yield
      processing_queue << message
      puts "Added message to queue: #{message}"
    else
      puts "Sent queue status: #{queue_size}"
    end
  end
end

receiver_ractor.send(1)
receiver_ractor.send(2)
receiver_ractor.send(3)
puts "Finished submissions"

sleep(0.5)

receiver_ractor.take # force refresh status
puts "Receiver queue length: #{receiver_ractor.take}"

sleep(1)

receiver_ractor.take # force refresh status
puts "Receiver queue length: #{receiver_ractor.take}"

Here’s how this looks when it executes:

<internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
Finished submissions
Added message to queue: 1
Added message to queue: 2
Added message to queue: 3
Sent queue status: 3
Sent queue status: 3
Receiver queue length: 3
Processed from queue: 1
Processed from queue: 2
Processed from queue: 3
Sent queue status: 3
Sent queue status: 0
Receiver queue length: 0

And here’s the timeline:

The main Ractor sends three messages to the receiver_ractor, containing 1, 2 and 3
The main Ractor goes to sleep
The receiver Ractor wakes up, reads the three messages, and redirects them to the processing_queue
The main Ractor wakes up, forces a refresh of the queue_size (see below for more details)
The main Ractor calls take, observes the queue_size is 3
The main Ractor goes to sleep
The receiver Ractor’s second thread wakes up and processes the three messages: 1, 2 and 3
The main Ractor wakes up, forces a refresh of the queue_size (again) — notice that this refresh was needed, because the value was outdated (goes from 3 to 0)
The main Ractor observes that the queue is empty!

Inside the receiver Ractor, this strategy works as follows: There are now two threads. One of the threads uses Ractor.select to do two things at once — either receive new items for processing, putting them on a regular thread-safe queue, or returning back the current size of the queue. The second thread just processes items from the thread-safe queue.

The sender can now either use send to send items, or call take twice to get the size of the queue. Why twice? Because this value is only refreshed before select gets called, if a long time passes between select is entered and any calls to send or take, this value can become outdated, as happened the example above. Calling take twice in a row guarantees that we get a "fresh" value — we know the value was just refreshed for the second take.

Building atop this construction, we can implement a number of strategies for better communication between two Ractors. For instance, we can review the original example to make sure that the sender never runs "too far ahead" the receiver:

receiver_ractor = Ractor.new do
  processing_queue = Queue.new

  Thread.new do
    loop do
      message = processing_queue.pop
      sleep(1)
      puts "Processed #{message}"
    end
  end

  loop do
    queue_size = processing_queue.size
    sender, message = Ractor.select(Ractor.current, yield_value: queue_size)

    if sender != :yield
      processing_queue << message
      puts "Added message to queue: #{message}"
    else
      puts "Sent queue status: #{queue_size}"
    end
  end
end

counter = 0
while true
  counter += 1
  receiver_ractor.send(counter)

  if counter % 10 == 0
    receiver_ractor.take # force refresh status
    queue_size = receiver_ractor.take
    if queue_size > 5
      puts "Ractor is falling behind (#{queue_size} elements unprocessed); sleeping for a while"
      sleep(1) while (receiver_ractor.take && receiver_ractor.take > 1)
    end
  end
end

And here’s how it looks:

<internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
Added message to queue: 1
Added message to queue: 2
Added message to queue: 3
Added message to queue: 4
Added message to queue: 5
Added message to queue: 6
Added message to queue: 7
Added message to queue: 8
Added message to queue: 9
Added message to queue: 10
Sent queue status: 10
Sent queue status: 9
Ractor is falling behind (9 elements unprocessed); sleeping for a while
Sent queue status: 9
Sent queue status: 9
Processed 1
Sent queue status: 9
Sent queue status: 8
Processed 2
Sent queue status: 8
Sent queue status: 7
Processed 3
Sent queue status: 7
Sent queue status: 6
Processed 4
Sent queue status: 6
Sent queue status: 5
Processed 5
Sent queue status: 5
Sent queue status: 4
Processed 6
Sent queue status: 4
Sent queue status: 3
Processed 7
Sent queue status: 3
Sent queue status: 2
Processed 8
Sent queue status: 2
Sent queue status: 1
Added message to queue: 11
Added message to queue: 12
Added message to queue: 13
Added message to queue: 14
Added message to queue: 15
Added message to queue: 16
Added message to queue: 17
Added message to queue: 18
Added message to queue: 19
Added message to queue: 20
Sent queue status: 11
Sent queue status: 11
Ractor is falling behind (11 elements unprocessed); sleeping for a while

Sleeping is a very simplistic solution, but gets the job done. Other alternatives could be to switch to synchronous communication, or to instead submit the work to a different Ractor/code path.

That’s it for my first experiment with Ractors!

Looking into Array memory usage in Ruby

Thu, 11 Feb 2021 00:00:00 +0000

What’s the memory impact of keeping a number of objects in a Ruby array? To answer this question, I decided to look into how exactly arrays are internally represented by Ruby.

Note that because we’ll be looking at the Ruby internals, these results may and do change between Ruby versions; Nevertheless, the techniques used to measure overheads should be reusable for newer Ruby versions. Note also that the results I present here only apply to the official Ruby "MRI" implementation, not to JRuby or TruffleRuby.

So, let’s dive in!

What’s in a Ruby object?

Ruby objects are represented on your application’s heap memory using a struct RVALUE. Note that this struct is what is called a union — it can actually adopt a number of different layouts for keeping data inside of it, which is taken advantage of by the multiple Ruby built-in data structures. Note that this optimization is only available for parts of the VM implementation written in C, so unfortunately, regular Ruby objects cannot take advantage of these layouts to be more efficient.

Usually on modern machines this struct RVALUE occupies 40 bytes. We can confirm this using the MRI Ruby-specific API ObjectSpace.memsize_of(obj):

require 'objspace'

puts RUBY_DESCRIPTION
puts "Size of new object: #{ObjectSpace.memsize_of(Object.new)}"

## Output:
# ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux]
# Size of new object: 40

As expected, a new object takes up 40 bytes. As you may have noticed, I’ll be using Ruby 3.0.0 for the examples.

Let’s talk Arrays

A Ruby array can actually take two different shapes — let’s call them embedded and extended.

Arrays in Ruby are represented internally using a struct RArray; this is one of the layouts that can be adopted by a struct RVALUE.

The embedded shape

Because arrays do not need to store a lot of extra metadata (they are quite simple objects), there’s leftover space in the 40 bytes of a struct RVALUE to store a few array items in the struct itself. This is controlled by the RARRAY_EMBED_LEN_MAX constant, which for the Ruby releases I checked, is set to 3.

So whenever a new array is created with 0 to 3 elements, the embedded shape which fits within 40 bytes is used:

require 'objspace'

puts "Size of empty array: #{ObjectSpace.memsize_of([])}"
puts "Size of array of size 1: #{ObjectSpace.memsize_of(['a'])}"
puts "Size of array of size 2: #{ObjectSpace.memsize_of(['a', 'b'])}"
puts "Size of array of size 3: #{ObjectSpace.memsize_of(['a', 'b', 'c'])}"

## Output:
# Size of empty array: 40
# Size of array of size 1: 40
# Size of array of size 2: 40
# Size of array of size 3: 40

What happens after the fourth element?

The extended shape

From the fourth element on, the extended shape for the Array is used instead: a separate C array is allocated in memory to keeps pointers to each array element. A Ruby array using this shape will now occupy 40 bytes (for the struct RVALUE) + number of elements * machine word size (usually 8 bytes — 64 bits).

So for an array with four elements we’ll have: 40 + 4 * 8 = 72 bytes being used, and so on for the next elements:

require 'objspace'

puts "Size of array of size 4: #{ObjectSpace.memsize_of(['a', 'b', 'c', 'd'])}"
puts "Size of array of size 5: #{ObjectSpace.memsize_of(['a', 'b', 'c', 'd', 'e'])}"

## Output:
# Size of array of size 4: 72
# Size of array of size 5: 80

Up until now I’ve been showing how much space is used when an array is pre-created with some number of elements. But does all of this still apply we modify an existing array?

And what does Ruby really do when an array needs to grow or shrink?

Growing an Array

What happens when an array needs to grow to accommodate new elements? As expected, an embedded array will keep on using that shape while it can:

require 'objspace'

example_array = []
puts "Size of example array: #{ObjectSpace.memsize_of(example_array)}"
example_array << 'a'
puts "Size of example array: #{ObjectSpace.memsize_of(example_array)}"
example_array << 'b'
puts "Size of example array: #{ObjectSpace.memsize_of(example_array)}"
example_array << 'c'
puts "Size of example array: #{ObjectSpace.memsize_of(example_array)}"

## Output:
# Size of example array: 40
# Size of example array: 40
# Size of example array: 40
# Size of example array: 40

But you may be surprised to see what happens after we add the next element:

require 'objspace'

example_array = ['a', 'b', 'c']
puts "Size of example array: #{ObjectSpace.memsize_of(example_array)}"

example_array << 'd'
puts "Size of example array: #{ObjectSpace.memsize_of(example_array)}"

## Output:
# Size of example array: 40
# Size of example array: 200

Why 200 bytes and not the 72 bytes we saw above?

This is the Ruby VM doing a trade-off between space (memory) and time (CPU processing): expanding the underlying C array entails creating a new one with a bigger size, copying the existing elements onto this new array, and then finally adding the new element.

Because this is an expensive operation, Ruby tries to avoid doing it on every insertion, and thus instead adds some slack: in this case it jumps from 3 to (200 - 40) / 8 = 20 elements. Thus the trade-off: to avoid doing this expansion on every insertion (reduce CPU processing) we use up more space (memory) than may end up being actually needed.

What if we know in advance how many more elements we want to add?

Array.new(capacity) allows an array to be created with a given capacity. If, after that, you only work within this capacity, the array will keep its size.

If, on the other hand, you’d like to resize an array sometime after creating it, that’s not possible. An array can only be sized-to-fit at creation, and it’s not possible to ask Ruby to resize it to a specific size afterwards — Ruby will self-manage the size of the underlying memory.

Shrinking an Array

When elements are removed from an array, does it ever shrink? The answer is yes, but again Ruby will try to avoid shrinking/growing the array too often, so it will always leave some slack:

require 'objspace'

example_array = ['a', 'b', 'c']
example_array << 'd'
puts "Size of example array: #{ObjectSpace.memsize_of(example_array)}"

example_array.pop
puts "Size of example array: #{ObjectSpace.memsize_of(example_array)}"

## Output:
# Size of example array: 200
# Size of example array: 104

To force an array to shrink to size, you can use Array#compact. This returns a new sized-to-fit array:

require 'objspace'

example_array = ['a', 'b', 'c']
example_array << 'd'
puts "Size of example array: #{ObjectSpace.memsize_of(example_array)}"

compact_array = example_array.compact
puts "Size of example array: #{ObjectSpace.memsize_of(compact_array)}"

## Output:
# Size of example array: 200
# Size of example array: 72

That’s it for our tour of Ruby arrays!

Updated 2022-09: Updated post to call shapes embedded/extended rather than inline/regular as the former are commonly used in the Ruby community.

What I've been reading: December+January 2021 Edition

Sat, 06 Feb 2021 00:00:00 +0000

This blog post is a continuation of my ongoing experiment with collecting and summing up the best technical (with a bit of non-technical) stuff I’ve read and watched recently.

(P.s.: You can now receive my blog as a newsletter!)

Happy reading!

1. Painting a Selfie Girl, with Maths (YouTube Video):

Inigo Quilez is a master computer graphics artist, and in this video he paints a picture of a girl taking a selfie, using only code. Even cooler, the code is available on the Shadertoy website, where you can play with it in real-time, in your browser!

2. LiFi (Product):

Is the future of wireless networking the use of light? pureLiFi is proposing the use of light modulation (aka blinking lights so fast that the human eye can’t spot them) as a solution to some of our wifi woes.

The idea seems interesting, and I really got a laugh out of their FAQ:

Q: Will LiFi work in my pocket?

A: No LiFi does not work in your pocket, unless you have a transparent suit.

3. Nonlinear increases in complexity make unification excruciating (Blog Post):

Jessica Kerr makes a really good case for not allowing the allure of the "magical all-encompassing unified platform" to limit innovation and raise maintenance costs.

A key observation is that the cost of changes to a system grows non-linearly; complexity grows way faster than value.

4. On the Metal: Kenneth Finnegan (Podcast Episode):

The On the Metal podcast has quite entertaining guests talking about their background on hardware and software design, usually with a good amount of discussion of how computing has evolved and what we can learn from it.

On this episode, Kenneth Finnegan and a few friends decided to start running their own internet service provider for the lulz, and things went really deep from there. If you’ve ever wondered how some of the elders of the internet keep the lights on, this episode is for you.

5. Java Flight Recorder will support event throttling (Erm… JIRA ticket):

This new feature will enable low-overhead always-on memory allocation tracking for Java. Previously, trying to get this information out of the JVM could lead to a lot of overhead.

(Compared to the other items, this is a bit specific, but hey, it’s pretty cool that this feature was contributed by my colleague Jaroslav Bachorík!)

6. Napkin Math (Blog Posts):

Simon Hørup Eskildsen explores how with a bit of math that fits on a napkin, one can explore problem spaces and estimate rough system performance.

It’s quite insightful to follow along, and even more interesting to try to solve the problems as well.

GitHub solved the problem of the annoying "allow cookie banners" that try to tackle us on every website.

Their great solution: They removed all tracking cookies. For all customers. Even outside the EU. That’s it. No more list of 2000+ advertisers.

Not a solution for every business, but something that should really be applauded. I’ve removed google tracking and disqus comments from the blog recently as well; good riddance.

8. Ditherpunk — The article I wish I had about monochrome image dithering (Blog Post):

Dithering is a technique for choosing and placing colors from a limited palette in such a way that our brain "sees" more colors than really are there.

For instance, there are a lot less colors being used in this screenshot of Monkey Island than may appear at first sight:

This amazing blog post introduces and explores how dithering works, going from the simplest algorithm to nicer implementations that produce better results.

9. Towards Continuous Performance Regression Testing (Blog Post):

This blog post introduces JfrUnit, a Java tool that enables unit tests to integrate with the Java Flight Recorder.

Using JfrUnit, a developer can augment tests with checks that validate how much memory was allocated, how much I/O was performed, etc.

Although I expect that too strict usage of such a toolkit can lead to a somewhat brittle test suite that can break with JDK and OS, the concept does seem quite powerful when used correctly.

10. Performance Summit London Edition II (Online Event):

This free online event gathers engineers that are working on tackling performance challenges — from building tooling to making massive systems scale.

11. Programming-Idioms Cheatsheets (Website):

This website allows you to pick one or more programming languages, and to get a cheat sheet of now to perform many common operations in those languages.

For instance — here’s a pair that I quite like: Ruby and Kotlin.

More soon! I gathered quite a few links these past couple of months :)

What I've been reading: November 2020 Edition

Wed, 02 Dec 2020 00:00:00 +0000

This blog post is a continuation of my ongoing experiment with collecting and summing up the best technical (with a bit of non-technical) stuff I’ve read and watched this past month.

I’m still experimenting with the format, so feedback is definitely welcome.
(P.s.: You can now subscribe to my newsletter too!)

This month I’ve gone a bit down the rabbit hole of the GDC (Game Developers Conference) youtube archives. Even if you’re not interested in the gaming industry, there’s amazing engineering and design efforts going on there, and there’s a lot to be learned from the top companies in that field.

1. Magic: the Gathering: Twenty Years, Twenty Lessons Learned (Conference Talk):

This talk is a masterclass in design. Replace player with user and game with product and every single item still applies and is incredibly relevant. If you watch one talk I link to in this post, make it this one!

2. Up Sht Creek: Pro Tips for Managing the Unmanageable Project* (Conference Talk):

The presenter describes her experience on being brought into software (game) projects that are spiraling out of control, and their approach and recommendations to "turn the ship around" and make the project a success.

3. 50 Game Camera Mistakes (Conference Talk):

This talk is not generally applicable as the others above, but a through analysis into how much goes into making something that seems as simple as "the camera" behave in such a way that you never even notice it is there.

4. Game Balance Concepts (Blog Posts):

I’ve ran into this collection of blog posts by Ian Schreiber for his class on Game Balancing. I’m still going through them, but I really liked Level 4: Probability and Randomness as a great refresher on probability (and got stuck on the monty hall problem as well), and Level 3: Transitive Mechanics and Cost Curves with a really interesting analysis of how costs work in Magic: The Gathering.

5. BPF binaries: BTF, CO-RE, and the future of BPF perf tools (Blog Post):

If you haven’t heard about eBPF/BPF, it’s an amazingly interesting tool that was added to the Linux kernel, and that allows tiny scripts to be run inside the kernel itself. Its origins come from networking — you could use it to write very flexible + efficient firewall rules, but it’s now possible to use it to instrument many many things in the kernel, enabling A LOT of new observability and debugging use cases (as well as profiling, my main interest!).

But thus far getting it to work is still a bit awkward: the API is still being expanded, so many features need very recent Linux kernels, and often you need to compile your eBPF application with the headers of the exact kernel it’s going to run on. This blog post details the ongoing work to solve this by making eBPF applications portable.

6. Getting noticed as a remote engineer – and why it matters (Blog Post):

A few things that remote engineers should keep in mind when working remotely.

7. Breakpoint Day 1.4: Technology constraints drive automation (Talk):

Shopify’s director of production engineering describes the approach taken by his team to boost their tech stack through careful selective standardization while also being open to evolution and feedback, and in cooperating with the product teams that need to deliver using the stack daily.

A very though-provoking presentation, as this approach doesn’t seem to be very common in the industry: many other companies either have a lot more freedom in the software stack, but then have a lot of integration headaches and duplicated efforts, or they have a very strict top-down mandate on their whole tech stack, but are very closed to evolution, feedback, and re-evaluating their choices.

Shopify more and more seems to be a company to be on the look out for ;)

8. One Size Fits None - (Everything You Learned in Your DBMS Class is Wrong) (Talk):

A critique of the database design foundations that were (and still are?) taught to students, driven by a careful analysis on how databases are used nowadays: by whom, using which data, on which hardware, and with what expectations of performance, reliability and cost.

This talk is presented by Michael Stonebraker, which has a Turing award for his 40+ years of research and contributions on the field of databases, so he knows a thing or two about the foundations of the field.

9. THE TYRANNY of STRUCTURELESSNESS (Essay):

This thoughtful analysis, written in the context of female rights movement, but completely applicable to every such group, discusses how groups and organizations that decide to be entirely without structure end up coming short, because in the absence of a formal structure, informal structures (elites) spring up, and how that ends up blocking such a group from attaining concrete goals (e.g beyond raising awareness).

10. The Impact of Toxic Influencers on Communities (Blog Post):

Great (and depressing) analysis of the patterns exhibited by toxic influencers in the context of online communities, how they establish themselves, and the behaviors that they display.

11. UX request: Tell, don’t hide (Blog Post):

How you really shouldn’t hide UX elements when a given user doesn’t have permissions to access them, because then the users can’t tell what’s going on.

If options would show up on a given screen, disable, rather than hide them!

12. ARM and Lock-Free Programming (Blog Post):

With the release of Apple’s M1 chips, excitement over ARM CPUs seems to be at an all-high (and the chips do look amazing).

This blog post discusses how the ARM architecture has a weaker memory model than our usual x86 machines, and how it can break low-level concurrency code that accidentally relied on having a stricter model.

Creating a newsletter!

Tue, 01 Dec 2020 00:00:00 +0000

I’ve been listening to “Company of One” (which I do recommend) and that got me thinking that it may be cool to allow readers to subscribe to the blog via e-mail.

So I’ve decided to setup a newsletter! You can sign up by clicking here.

Or, if you’re a RSS feeds person, you can subscribe via https://ivoanjo.me/feed.xml as well.

That’s it for today! :)

What I've been reading: October 2020 Edition

Tue, 03 Nov 2020 00:00:00 +0000

A few years ago, I acquired the habit of regularly collecting and sharing with my work colleagues the highlights of what I was reading from week to week. As I’m preparing to start working at a new company soon, I’ve been wondering if it would be useful to share this with a wider audience, and how I would do it.

I’ve decided that the easiest way to start is to use this blog. I’m not sure how often I’ll do these, or if I’ll end up creating a separate section to avoid drowning out my more specific posts with just what I read on X month ones, but in the spirit of agile and YAGNI, here’s my first stab at sharing what I’m reading.

I don’t often get feedback, but it’s definitely welcome as always — let me know what you’ve thought of these articles and the format in general :)

Without further ado, here’s what’s been keeping me interested:

Why Aren’t More Users More Happy With Our VMs? Part 1 and Part 2 (Blog Post): A writeup and analysis on how VM benchmarking often gets done wrong, including the benchmarking done by VM implementors, and how that can lead to wrong optimizations or trade-offs being taken as a result.
Rework (Book): Describes the approaches championed by Jason Fried, David Heinemeier Hansson on managing their company Basecamp, and what we can learn from them. Its focus on staying small and doing more with less really resonated with what I’m thinking these days. (There’s an audiobook version as well!)
Nice performance improvement landing in Python 3.10 (Tweet):

Python 3.10 will be up to 10% faster: https://t.co/7ydQ4iATsN. Here's the email that I wrote to python-dev 4.5 years ago with some perf ideas: https://t.co/tuJL7yXmjZ. Thanks to @pyblogsal for picking up my patch and polishing it to get it merged. 🚀
— Yury Selivanov (@1st1) October 20, 2020

OpenJDK: add diagnostic command to write Linux perf map file (Pull Request): This pull request adds native support for the jcmd tool to generate the symbols needed when profiling OpenJDK with the Linux perf tool, without needing to use the third-party perf-map-agent. Translation: One less step to worry about when profiling using perf — the JVM will now do the generation itself.
Building Netflix’s Distributed Tracing Infrastructure (Blog Post): Deep dive on a distributed tracing design that allows very flexible sampling decisions (up to 100% for a specific subset of requests, even), as well as how to handle storing data from traces using a combination of architectural improvements, late sampling, compression and tiered storage.
Faster CPython (Website): Collects a number of ideas, experiments and measurements around improving the performance of the CPython interpreter.
Pitfalls of Object Oriented Programming (PDF Presentation): This presentation discusses how some common object-oriented idioms can cause bottlenecks in high-performance realtime applications (*cof* games *cof*) and how to refactor and break apart such approaches to extract more performance.
When busy-spining Java thread is bound to physical core, can context switch happen by the reason that new branch in code is reached? (Discussion): This Stack Overflow question triggered an amazing answer by Andrei Pangin (the author of async-profiler) discussing how and when the JVM interrupts user code to perform optimizations and measurements.
Dynamically Typed Languages (PDF Article): Interesting discussion on how dynamic languages differ from static languages, and what they have to offer.
Magic-Wormhole: Get Things From One Computer To Another, Safely (Tool): Small tool to securely transfer data between two computers, even behind firewalls and whatnot.
Enter the Vault: Authentication Issues in HashiCorp Vault (Blog post): Deep dive discussion into two recent issues with the Vault system for securing access to credentials. It highlights how even an apparently solid design can be breached by exploiting wrong assumptions and incomplete implementations when such system is integrated with third-party APIs.
INSPIRED: How to Create Tech Products Customers Love (Book): Describes what and how a product managers can work together with engineering teams and other company stakeholders to discover and deliver really good solutions to customer’s issues.

It took me a few months to go through the entire book, but I cannot recommend it enough — even for, and especially for engineers that regularly work with product managers. I especially liked the "missionaries vs mercenaries" categorization of product teams, as it really aligns with my own experience in the field. (There’s an audiobook version as well!)
Nebula: A collection of Gradle plugins, built by Netflix (Tool): The Netflix nebula set of plugins extends the Gradle built tool with a number of nice features — better metadata, a dependency.lock file that works like Ruby’s Gemfile.lock/gems.locked and enables reproduceable builds via locking of dependency versions, ways to manage versioning and deployment, etc.

This set of plugins is really interesting, and especially the version locking features are something that I never quite understood why/how people were getting by without them in the JVM ecosystem. Glad to see that Netflix’s engineering agrees with me ;)
Performance Summit IV (Conference): Upcoming free online conference with talks from engineers working in the performance profiling space.

I’m particularly interested in seeing the "BPerf: Porting production profiling from Windows to Linux" talk describing the ongoing work to bring Windows' ETW tooling to Linux, as I’ve been fascinated in the past months by that toolkit, that I can describe as similar to Java’s Flight Recorder tooling, but at the OS level; as well as "Perflections: Tracking the perf of perf programs" as I’m also quite curious on how to safely use and deploy perf-based solutions directly to customers (e.g. when you’re no longer using it on your local infrastructure).
Raygun (Tool): Another hosted Ruby APM; uses flame charts for visualizing traces.
Technology Radar, volume 23 (Magazine): The latest version of Thoughtwork’s influential periodic review of techniques, tools, platforms and languages & frameworks in the industry. As always, a recommended read.
eBPF superpowers (Talk): Great "hello world" introduction to Linux’s eBPF tooling:

That’s it for this round!

Better backtraces in Ruby using TracePoint

Sun, 19 Jul 2020 00:00:00 +0100

In a previous blog post — Ruby Experiment: Include class names in backtraces — I shared the beginning of my experiments into improving Ruby backtraces.

That got me thinking of a few things:

What information would I want to show in backtraces?
What format would I display that information in?
Is it possible (and reasonable?) to extract the needed information during backtrace collection?

To allow me to iterate faster, I’ve implemented my next prototype for better backtraces using Ruby’s TracePoint API.

This means that the current prototype can be run on regular unmodified Ruby, although having it loaded will have a performance impact (so I definitely don’t recommend it).

The result of my experiments is the following:

tracepoint-better-backtrace.rb:159:in BetterBacktrace.better_backtrace_locations(thread)
tracepoint-better-backtrace.rb:2:in ClassA#hello()
tracepoint-better-backtrace.rb:11:in ModuleB::ClassB#hello()
tracepoint-better-backtrace.rb:18:in ModuleC.hello()
tracepoint-better-backtrace.rb:24:in ClassWithStaticMethod.hello()
tracepoint-better-backtrace.rb:30:in ModuleD#hello()
tracepoint-better-backtrace.rb:39:in Object$singleton#<main>{block}()
tracepoint-better-backtrace.rb:41:in Object$singleton#<main>{block}()
tracepoint-better-backtrace.rb:47:in ClassD$singleton#hello()
tracepoint-better-backtrace.rb:52:in ClassE#hello()
tracepoint-better-backtrace.rb:73:in Method#call(*)
tracepoint-better-backtrace.rb:72:in ClassG$refinement@ContainsRefinement::RefinesClassG#hello()
tracepoint-better-backtrace.rb:82:in ModuleE.hello()
tracepoint-better-backtrace.rb:88:in ClassH#method_missing(name, *_)
tracepoint-better-backtrace.rb:97:in ClassF#hello{block}()
tracepoint-better-backtrace.rb:97:in Integer#times()
tracepoint-better-backtrace.rb:96:in ClassF#hello(arg1, arg2, test1, test2)
tracepoint-better-backtrace.rb:105:in #<Class:#<Object:0x00005636e9ea3898>>.hello()
tracepoint-better-backtrace.rb:110:in #<Class:0x00005636e9ea35c8>#hello()
tracepoint-better-backtrace.rb:116:in #<Module:0x00005636e9ea32d0>.hello()
tracepoint-better-backtrace.rb:121:in Object#method_with_complex_parameters(a, b, *c, (), f:, g:, **h, &i)
tracepoint-better-backtrace.rb:125:in Object#top_level_hello()
tracepoint-better-backtrace.rb:229:in Kernel#eval(*)
tracepoint-better-backtrace.rb:228:in Object$singleton#<main>{block}()
tracepoint-better-backtrace.rb:228:in Integer#times()
tracepoint-better-backtrace.rb:227:in Object$singleton#<main>{block}()
tracepoint-better-backtrace.rb:227:in Integer#times()

The changes are:

Show class/module names
Show number and names of arguments next to method names
Distinguish between instance methods (Foo#bar) and methods defined on class/method objects (Foo.bar). The # vs . syntax follows from the usual conventions in Ruby documentation.
Display methods defined on specific objects with the $singleton suffix
Display refinements as the $refinement suffix, followed by the name of the module that defined the refinement
Show blocks as {block} (instead of block in …)
The eval frame (shown below as (eval):1:in `block (2 levels) in <main>') was omitted — this seems to be a gap in the TracePoint API

It took me quite a while (and a few discussions with friends and colleagues — thanks João and Marek for nice points) but I’m reasonably happy with the current way of encoding all this information in a backtrace.

All of these data points are stored separately in the "backtrace information" so alternative representations (or just not showing this much information) is doable by just changing the printing bits.

My test file is a quite artificial example: the usual Ruby conventions would be to have classes defined in a separate file. But, for reference, here’s how a regular Ruby backtrace looks for the same file:

tracepoint-better-backtrace.rb:5:in `backtrace_locations'
tracepoint-better-backtrace.rb:5:in `hello'
tracepoint-better-backtrace.rb:12:in `hello'
tracepoint-better-backtrace.rb:19:in `hello'
tracepoint-better-backtrace.rb:25:in `hello'
tracepoint-better-backtrace.rb:31:in `hello'
tracepoint-better-backtrace.rb:39:in `block in <main>'
tracepoint-better-backtrace.rb:41:in `block in <main>'
tracepoint-better-backtrace.rb:48:in `hello'
tracepoint-better-backtrace.rb:53:in `hello'
tracepoint-better-backtrace.rb:73:in `call'
tracepoint-better-backtrace.rb:73:in `hello'
tracepoint-better-backtrace.rb:83:in `hello'
tracepoint-better-backtrace.rb:91:in `method_missing'
tracepoint-better-backtrace.rb:98:in `block in hello'
tracepoint-better-backtrace.rb:97:in `times'
tracepoint-better-backtrace.rb:97:in `hello'
tracepoint-better-backtrace.rb:106:in `hello'
tracepoint-better-backtrace.rb:111:in `hello'
tracepoint-better-backtrace.rb:117:in `hello'
tracepoint-better-backtrace.rb:122:in `method_with_complex_parameters'
tracepoint-better-backtrace.rb:126:in `top_level_hello'
(eval):1:in `block (2 levels) in <main>'
tracepoint-better-backtrace.rb:229:in `eval'
tracepoint-better-backtrace.rb:229:in `block (2 levels) in <main>'
tracepoint-better-backtrace.rb:228:in `times'
tracepoint-better-backtrace.rb:228:in `block in <main>'
tracepoint-better-backtrace.rb:227:in `times'
tracepoint-better-backtrace.rb:227:in `<main>'

Below, you’ll find tracepoint-better-backtrace.rb file, which includes the implementation, as well as the most extensive example for defining classes and methods in different ways in Ruby that I could think of :)

The implementation uses a "shadow stack": it keeps a separate stack as a thread-local variable that simulates the real Ruby stack by pushing and popping information on the current active methods as they are entered and they finish. To generate the backtrace, we just need to access the current state of that variable.

The key parts of the implementation are which information is gathered on method entry (inside the TracePoint definition block), as well as how those data points are interpreted to generate the pretty stack (inside to_s for the Locations struct).

What’s next? I’ve been experimenting with implementing these improved backtraces in the rbspy Ruby profiler.

Because the rbspy profiler works outside of the Ruby VM, it can gather the extra needed information without impacting the performance of the Ruby VM, so it seems like a great place to start with a real-world implementation of these better backtraces.

Snippet: Getting a dynamically-generated method name on the Java stack using Javassist

Sun, 12 Jul 2020 00:00:00 +0100

Have you ever found yourself in need to include a certain string or method name on your stack traces, for debugging or metrics?

The following snippet shows how easy that can be done with the javassist library. The snippet is written in Kotlin, but can be easily converted into Java or any other JVM language.

For the example, we want to see "iLikePie" as one of our method names. Here’s how it looks:

Your stack is:
java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:1336)
        at Dynamic_framesKt$main$$inlined$withFrameNamed$1.get(dynamic-frames.kt:51)
        at dynamic.iLikePie.iLikePie(iLikePie.java)
        at dynamic.iLikePie.apply(iLikePie.java)
        at Dynamic_framesKt.main(dynamic-frames.kt:57)

…and here’s the code to implement it.

#!/usr/bin/env kscript
//DEPS org.javassist:javassist:3.24.1-GA

import javassist.ClassPool
import javassist.CtMethod
import java.util.function.Function
import java.util.function.Supplier

val classPool = ClassPool.getDefault()
val generatedClasses: MutableMap<String, Function<Supplier<Any>, Any>> = mutableMapOf()

fun dynamicFrameNamed(name: String): Function<Supplier<Any>, Any> {
    val dynamicClass = classPool.makeClass("dynamic.$name").apply {
        addInterface(classPool.get("java.util.function.Function"))

        addMethod(CtMethod.make("""
            private Object $name(java.util.function.Supplier block) {
                return block.get();
            }
        """, this))

        addMethod(CtMethod.make("""
            public Object apply(Object o) {
                java.util.function.Supplier block = (java.util.function.Supplier) o;
                return $name(block);
            }
        """, this))

    }

    return dynamicClass.toClass().newInstance() as Function<Supplier<Any>, Any>
}

inline fun withFrameNamed(name: String, crossinline block: () -> Unit) {
    generatedClasses
        .getOrPut(name) { dynamicFrameNamed(name) }
        .apply(object : java.util.function.Supplier<Any> {
            override fun get(): Any {
                block()
                return ""
            }
        })
}

fun main(args: Array<String>) {
    withFrameNamed("iLikePie") {
        println("Your stack is:")
        Thread.dumpStack()
    }
}

Ruby Experiment: Include class names in backtraces

Sun, 05 Jul 2020 00:00:00 +0100

As a weekend experiment, I decided to write a few prototypes to answer the following question: Is it possible to improve Ruby backtraces by including the class where a given method was defined, similar to how Java and other languages do it?

Turns out that it can be done with a handful of changes in the implementation of backtraces: https://github.com/ivoanjo/ruby/commit/cfa29197cb9f98866ef9c77662f49ba9fdf351a3.

This allows the following example:

module A
  class Super1
    def classes_example
      print_stack_trace(Thread.current.backtrace_locations)
    end
  end
end

module B
  class Super2 < A::Super1
    def classes_example
      super
    end
  end
end

module C
  class Super3 < B::Super2
    def classes_example
      super
    end
  end
end

module D
  class Super4 < C::Super3
    def classes_example
      super
    end
  end
end


puts "Stack for classes_example:"
D::Super4.new.classes_example

…to be printed as:

Thread.backtrace_locations(rich_stack_trace_example.rb:42)
A::Super1.classes_example(rich_stack_trace_example.rb:42)
B::Super2.classes_example(rich_stack_trace_example.rb:50)
C::Super3.classes_example(rich_stack_trace_example.rb:58)
D::Super4.classes_example(rich_stack_trace_example.rb:66)
Object.<main>(rich_stack_trace_example.rb:73)

…instead of the more usual:

rich_stack_trace_example.rb:42:in `backtrace_locations'
rich_stack_trace_example.rb:42:in `classes_example'
rich_stack_trace_example.rb:50:in `classes_example'
rich_stack_trace_example.rb:58:in `classes_example'
rich_stack_trace_example.rb:66:in `classes_example'
rich_stack_trace_example.rb:73:in `<main>'

It’s not completely perfect for other cases (modules, singleton definitions, etc) — I hope to look into that in the future.

Quick tip: Unsafe concurrent Ruby hash access

Mon, 26 Aug 2019 00:00:00 +0100

On my talk on spotting unsafe concurrent ruby patterns I documented a few common Ruby code patterns that may trigger issues when executed concurrently across multiple threads.

I just bumped into another such example! This specific one seems not to affect MRI Ruby (aka the default Ruby implementation), but I was able to clearly trigger it on both JRuby and TruffleRuby using

some_hash[key] = value

The trigger above is very simple — having different threads writing to the same Hash concurrently. Just writing, they don’t even need to be reading.

Here’s the full example:

puts RUBY_DESCRIPTION

PER_THREAD_LIMIT = 1000000
THREADS = 8

THE_HASH = {}

(1..THREADS).to_a.map do |thread_id|
  Thread.new do
    PER_THREAD_LIMIT.times do
      THE_HASH[rand(PER_THREAD_LIMIT)] = thread_id
    end
    puts "Thread #{thread_id} done!"
  end
end.map(&:join)

puts "All done!"

and here’s the result of running it on JRuby:

jruby 9.2.8.0 (2.5.3) 2019-08-12 a1ac7ff OpenJDK 64-Bit Server VM 11.0.3+7-LTS on 11.0.3+7-LTS +jit [linux-x86_64]
warning: thread "Ruby-0-Thread-3: threads.rb:1" terminated with exception (report_on_exception is true):
java.lang.ArrayIndexOutOfBoundsException: Index 18581 out of bounds for length 16427
        at org.jruby.dist/org.jruby.RubyHash.internalPutNoResize(RubyHash.java:561)
        at org.jruby.dist/org.jruby.RubyHash.internalPut(RubyHash.java:535)
        at org.jruby.dist/org.jruby.RubyHash.internalPut(RubyHash.java:525)
        at org.jruby.dist/org.jruby.RubyHash.fastASetCheckString(RubyHash.java:1020)
        at org.jruby.dist/org.jruby.RubyHash.op_aset(RubyHash.java:1055)
        at org.jruby.dist/org.jruby.RubyHash$INVOKER$i$2$0$op_aset.call(RubyHash$INVOKER$i$2$0$op_aset.gen)
        at org.jruby.dist/org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:203)
        at threads.invokeOther1:\=\{\}=(threads.rb:11)
        at threads.RUBY$block$\=threads\,rb$2(threads.rb:11)
        at org.jruby.dist/org.jruby.runtime.CompiledIRBlockBody.yieldDirect(CompiledIRBlockBody.java:146)
        at org.jruby.dist/org.jruby.runtime.IRBlockBody.yieldSpecific(IRBlockBody.java:85)
        at org.jruby.dist/org.jruby.runtime.Block.yieldSpecific(Block.java:139)
        at org.jruby.dist/org.jruby.RubyFixnum.times(RubyFixnum.java:279)
        at org.jruby.dist/org.jruby.RubyInteger$INVOKER$i$0$0$times.call(RubyInteger$INVOKER$i$0$0$times.gen)
        at org.jruby.dist/org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:151)
        at org.jruby.dist/org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:160)
        at threads.invokeOther3:times(threads.rb:10)
        at threads.RUBY$block$\=threads\,rb$1(threads.rb:10)
        at org.jruby.dist/org.jruby.runtime.CompiledIRBlockBody.callDirect(CompiledIRBlockBody.java:136)
        at org.jruby.dist/org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:77)
        at org.jruby.dist/org.jruby.runtime.Block.call(Block.java:129)
        at org.jruby.dist/org.jruby.RubyProc.call(RubyProc.java:295)
        at org.jruby.dist/org.jruby.RubyProc.call(RubyProc.java:274)
        at org.jruby.dist/org.jruby.RubyProc.call(RubyProc.java:270)
        at org.jruby.dist/org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:105)
        at java.base/java.lang.Thread.run(Thread.java:834)

Thread 5 done!
Thread 8 done!
Thread 4 done!
Thread 6 done!
Thread 2 done!
Thread 1 done!
Unhandled Java exception: java.lang.ArrayIndexOutOfBoundsException: Index 18581 out of bounds for length 16427
java.lang.ArrayIndexOutOfBoundsException: Index 18581 out of bounds for length 16427
   internalPutNoResize at org/jruby/RubyHash.java:561
           internalPut at org/jruby/RubyHash.java:535
           internalPut at org/jruby/RubyHash.java:525
   fastASetCheckString at org/jruby/RubyHash.java:1020
               op_aset at org/jruby/RubyHash.java:1055
                  call at org/jruby/RubyHash$INVOKER$i$2$0$op_aset.gen:-1
                  call at org/jruby/runtime/callsite/CachingCallSite.java:203
  invokeOther1:\=\{\}= at threads.rb:11
            threads.rb at threads.rb:11
           yieldDirect at org/jruby/runtime/CompiledIRBlockBody.java:146
         yieldSpecific at org/jruby/runtime/IRBlockBody.java:85
         yieldSpecific at org/jruby/runtime/Block.java:139
                 times at org/jruby/RubyFixnum.java:279
                  call at org/jruby/RubyInteger$INVOKER$i$0$0$times.gen:-1
                  call at org/jruby/runtime/callsite/CachingCallSite.java:151
              callIter at org/jruby/runtime/callsite/CachingCallSite.java:160
    invokeOther3:times at threads.rb:10
            threads.rb at threads.rb:10
            callDirect at org/jruby/runtime/CompiledIRBlockBody.java:136
                  call at org/jruby/runtime/IRBlockBody.java:77
                  call at org/jruby/runtime/Block.java:129
                  call at org/jruby/RubyProc.java:295
                  call at org/jruby/RubyProc.java:274
                  call at org/jruby/RubyProc.java:270
                   run at org/jruby/internal/runtime/RubyRunnable.java:105
                   run at java/lang/Thread.java:834

as well as on TruffleRuby:

truffleruby 19.1.1, like ruby 2.6.2, GraalVM CE Native [x86_64-linux]
Thread 1 done!
threads.rb:11:in `[]=': <no message> (NullPointerException) (RuntimeError)
        from org.truffleruby.core.hash.PackedArrayStrategy.getHashed(PackedArrayStrategy.java:41)
        from org.truffleruby.core.hash.SetNode.setPackedArray(SetNode.java:80)
        from org.truffleruby.core.hash.SetNodeGen.executeSet(SetNodeGen.java:37)
        from org.truffleruby.core.hash.HashNodes$SetIndexNode.set(HashNodes.java:239)
        from org.truffleruby.core.hash.HashNodesFactory$SetIndexNodeFactory$SetIndexNodeGen.execute(HashNodesFactory.java:632)
        from org.truffleruby.language.control.SequenceNode.execute(SequenceNode.java:34)
        from org.truffleruby.language.methods.ExceptionTranslatingNode.execute(ExceptionTranslatingNode.java:51)
        from org.truffleruby.language.RubyRootNode.execute(RubyRootNode.java:54)
        from org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.callProxy(OptimizedCallTarget.java:328)
        from org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.callRoot(OptimizedCallTarget.java:318)
Translated to internal error
        from threads.rb:11:in `block (3 levels) in <main>'
        from threads.rb:10:in `times'
        from threads.rb:10:in `block (2 levels) in <main>'

This happens because neither Ruby has synchronization when changing the internal structure of the Hash (which happens when for instance the hash needs to grow), and thus we can run into this issue.

Note also that this won’t happen every time, as this is a race condition, so your results may vary :)

How to fix it? Consider replacing the hash with a Concurrent::Map or wrapping it with a lock.

Kotlin Hack: Transparently replace class with interface

Sat, 10 Aug 2019 00:00:00 +0100

While working on an experiment using Kotlin recently, I ran into the following issue: I had a class — let’s call it FooInteractor — that I wanted to be able to replace with an implementation that did nothing in some cases.

I had other classes that referenced it, which I did not want to have to change. I also had several places where FooInteractor was instanced directly, via FooInteractor(…) which I also did not want to have to change.

So I had the following challenge: Can I somehow only change FooInteractor, without touching any other file, and still allow it to be easily replaced?

As an example, let’s use the following definition for FooInteractor:

class FooInteractor(private val repository: FooRepository) {
    fun call(val someArg: String) { /* ... */ }
}

Mocking frameworks?

This use-case also comes up quite often in tests, and there the amazing Mockito framework, or some similar tool is usually employed to automagically create an instance of FooInteractor that has no behavior (or that we can attach custom behavior to).

But, in this case, I wanted to avoid having to add a dependency to mockito for just this simple use case.

Solution part 1: Introducing an interface

The first step was introducing an interface to replace the concrete implementation:

interface FooInteractor {
    fun call(someArg: String)
}

class FooInteractorImpl(private val repository: FooRepository) : FooInteractor {
    override fun call(someArg: String) { /* ... */ }
}

By renaming FooInteractor to FooInteractorImpl and introducing an interface with exactly the same signature for its functions, all of the code that referenced the FooInteractor type transparently started using this interface.

…and I could now do this:

val emptyFoo = object : FooInteractor {
    override fun call(someArg: String) {
        println("Empty foo called with $someArg")
    }
}

And I could use this emptyFoo anywhere that takes a FooInteractor.

But, there was still an issue: what about places in the codebase that called the FooInteractor constructors?

Solution part 2: Faking the original class' constructor

Anywhere on my codebase where a FooInteractor was created via

val fooInteractor = FooInteractor(repository = someRepository)

was now failing, because FooInteractor just became an interface.

To solve this transparently, we can make use of the Invoke operator.

The invoke operator allows writing an expression such as someObject(…) as an alias of someObject.invoke(…). And funnily enough, constructors look exactly like that!

So yeah, a bit unexpectedly, we can use the invoke operator to make our new interface into a factory of implementation instances, transparently:

interface FooInteractor {
    companion object {
        operator fun invoke(repository: FooRepository) =
            FooInteractorImpl(repository)
    }

    fun call(someArg: String)
}

And our example code will now work, even though it is now calling the invoke function on the interactor interface, rather than the constructor directly:

val fooInteractor = FooInteractor(repository = someRepository)

And boom, done! We just introduced an interface by only changing the FooInteractor class, and the rest of the codebase remains 100% unchanged.

Here’s the full example, if you want to experiment with it:

#!/usr/bin/env kscript

// Save this as example.kts and use https://github.com/holgerbrandl/kscript to run it

class FooRepository() { /* ... */ }

interface FooInteractor {
    companion object {
        operator fun invoke(repository: FooRepository) =
            FooInteractorImpl(repository)
    }

    fun call(someArg: String)
}

class FooInteractorImpl(private val repository: FooRepository) : FooInteractor {
    override fun call(someArg: String) {
        println("Real foo called with $someArg")
    }
}

val emptyFoo = object : FooInteractor {
    override fun call(someArg: String) {
        println("Empty foo called with $someArg")
    }
}

val someRepository = FooRepository()
val realFoo = FooInteractor(repository = someRepository)

emptyFoo.call("Hello")
realFoo.call("World")

And the expected output:

Empty foo called with Hello
Real foo called with World

Kotlin for Rubyists

Tue, 05 Mar 2019 00:00:00 +0000

Although I’ve never seen Ruby cited as an inspiration for Kotlin, ever since I first ran into it, I couldn’t but notice how closely it resembles Ruby.

Kotlin shares many of Ruby’s niceties: you can do a lot with a very small amount of code; its standard library includes many useful tools that help you express your intent clearly; it can be used to create beautiful domain specific languages; it has an interactive shell; and it includes a number of functional constructs. Even its syntax is very Ruby-like at times — it has a block-lookalike!

So if they share many similarities, what does Kotlin bring to Rubyists? Quite a bit, actually.

If you find yourself needing to work or interoperate with a Java environment, Kotlin and its tooling were built to allow easy migration from Java. It’s very easy to incrementally move a codebase from Java to Kotlin, and there are even automatic translation tools. Yes, this also means that Kotlin can make use of all the niceties of the Java and JVM environment: just-in-time compilation, state-of-the-art garbage collection, first-class concurrency tooling, and its many, many libraries and frameworks. Additionally, it is also a first-class citizen and officially supported by Google as an alternative to Java when building Android applications.

For those seeking static validation, Kotlin is both statically typed and null-safe. Static typing ensures that a number of common errors happen at compile-time, when you’re preparing your code for execution, rather than at runtime (no more mysterious NoMethodErrors!). Null safety means that the compiler can distinguish between nullable and non-nullable types, and is able to enforce that if before calling a method on something that can be null (or nil), you’ve checked if the value is not null. Kotlin’s type system also includes a number of other niceties, such as zero-overhead inline classes that work as a kind of aliases to existing classes — e.g. you’ll be able to get a compile-time error if you try to assign a Password value to an Username field, even if both are actually compiled as String.

Kotlin can also be used for front-end development: It can be compiled into javascript code and easily work with common javascript libraries, it can understand TypeScript definitions, and can also by used on Node.js.

Last but not least, Kotlin can also be compiled — using LLVM — into an optimized machine code executable. This feature is still experimental, and it allows interoperating with compiled languages such as C/C++/Objective-C/Swift.

In short, although I remain a committed Ruby lover 😉, I believe that Kotlin deserves a place in every Rubyist’s toolkit.

Curious to check it out? At the 2019 edition of the awesome Ruby on Ice conference, I presented a workshop called “Kotlin for Rubyists”.

This workshop covered not only an introduction to the language, but also to the ecosystem: how to install it, which build system to use, testing, performance tooling, etc.

We also build several example applications (including a nice microservice). I’ve made available all of the example material on this git repository.

You can find the slide deck from the workshop embedded below:

Feedback is very welcome 😁

Spotting unsafe Ruby patterns - Talk recording

Sat, 13 Oct 2018 00:00:00 +0100

Writing Ruby code that uses multiple threads is a great way to get better performance and to take advantage of modern laptops and servers. It can also be quite daunting due to the often-feared “concurrency bugs”.

In this talk, recorded at the Fullstack LX Ruby meetup, I introduce a number of pitfalls to watch out for, presenting correct (and fast!) alternatives for each.

Slide deck:

Writing to a Java TreeMap concurrently can lead to an infinite loop during reads

Sat, 21 Jul 2018 00:00:00 +0100

The java.util.TreeMap documentation warns that the underlying implementation for this Map is not synchronized — and thus it is not thread-safe.

But have you ever wondered what happens if you ignore that warning and you write an application that concurrently writes to the map from different threads? Intuitively, I’d probably expect some entries to be lost, or to sometimes get a NullPointerException.

But did you know that — at least with the current implementation shipped on OpenJDK — you can actually corrupt the TreeMap in such a way that attempts to read the map will result in your code getting stuck on an infinite loop?

This happens because the TreeMap is implemented as a red-black tree, a self-balancing tree algorithm. As new elements are inserted into the tree, the tree is rebalanced — elements are moved around so that the tree is kept height-balanced. (See the Wikipedia article for details, as they explain a lot better than I do!)

When several threads are adding new entries to a TreeMap at the same time, those threads also compete to rebalance the tree concurrently. And because rebalancing entails changing several pointers, the result is that the tree may form internal loops — thus no longer being a tree.

The following application is able to show this issue. It repeatedly creates a new TreeMap, writes to it using two different concurrent threads, and then navigates the internal map structure using reflection to check if the TreeMap formed a loop. When it finds a loop, it prints it.

import java.util.*;
import java.lang.reflect.*;
import java.util.Map.Entry;

@SuppressWarnings("unchecked")
public class ConcurrentTreeMapLoopReproducer {
  public static void main(String ... args) throws Exception {
    System.out.println("Running on Java " + System.getProperty("java.version"));
    int insertUpTo = 20;
    if (args.length > 0) {
      insertUpTo = Integer.parseInt(args[0]);
    }
    System.out.println("Using insertUpTo=" + insertUpTo);

    new ConcurrentTreeMapLoopReproducer(insertUpTo).call();
  }

  TreeMap<Integer,Integer> brokenMap = null;
  int insertUpTo;

  ConcurrentTreeMapLoopReproducer(int insertUpTo) {
    this.insertUpTo = insertUpTo;
  }

  static class LoopStep {
    Entry<Integer,Integer> entry;
    String direction;
    LoopStep next;

    LoopStep(Entry<Integer,Integer> entry) { this(entry, null, null); }
    LoopStep(Entry<Integer,Integer> entry, String direction, LoopStep next) {
      this.entry = entry;
      this.direction = direction;
      this.next = next;
    }

    public String toString() {
      if (next != null) {
        return "" + entry.getKey() + " --" + direction + "--> " + next;
      } else {
        return entry.getKey().toString();
      }
    }
  }

  public void call() throws Exception {
    LoopStep loopPath = null;
    System.out.print("Attempting to trigger looping TreeMap");
    for (int attempts = 1; loopPath == null; attempts++) {
      System.out.print(".");
      System.out.flush();

      brokenMap = tryToTriggerLoopingTreeMap();
      loopPath = findLoop(brokenMap);
    }

    System.out.println("\nWas able to reproduce loop in map: " + loopPath);

    // Uncomment this to see the loop in action: This will never finish
    //brokenMap.values().toArray();
  }

  static TreeMap<Integer,Integer> tryToTriggerLoopingTreeMap() throws Exception {
    TreeMap<Integer,Integer> map = new TreeMap<>();

    Thread t1 = new Thread(() -> { for (int i = 0; i < 20; i += 2) try { map.put(i, i); } catch (Exception e) { } });
    Thread t2 = new Thread(() -> { for (int i = 1; i < 20; i += 2) try { map.put(i, i); } catch (Exception e) { } });
    t1.start();
    t2.start();
    t1.join();
    t2.join();

    return map;
  }

  static LoopStep findLoop(TreeMap<Integer,Integer> map) throws Exception {
    Field rootField = TreeMap.class.getDeclaredField("root");
    rootField.setAccessible(true);

    Entry<Integer,Integer> rootEntry = (Entry<Integer,Integer>) rootField.get(map);

    return findLoopRecursive(new ArrayList<>(), rootEntry);
  }

  static LoopStep findLoopRecursive(List<Entry<Integer,Integer>> currentPath, Entry<Integer,Integer> entry) throws Exception {
    if (entry == null) return null;

    if (currentPath.contains(entry)) {
      currentPath.add(entry);
      return new LoopStep(entry);
    }

    currentPath.add(entry);

    LoopStep result = null;

    result = findLoopRecursive(currentPath, get("left", entry));
    if (result != null) return new LoopStep(entry, "left", result);
    result = findLoopRecursive(currentPath, get("right", entry));
    if (result != null) return new LoopStep(entry, "right", result);

    currentPath.remove(entry);

    return null;
  }

  static Entry<Integer,Integer> get(String direction, Entry<Integer,Integer> parent) throws Exception {
    Field field = parent.getClass().getDeclaredField(direction);
    field.setAccessible(true);
    return (Entry<Integer,Integer>) field.get(parent);
  }
}

(Ufff. Java can get so verbose!)

Because this is a concurrency issue, this code is not always successful in triggering an issue.^[1]

On other runs, you may get an infinite loop during a put() operation.

But in most cases you’ll get something like this:

$ java ConcurrentTreeMapLoopReproducer
Running on Java 10
Using insertUpTo=20
Attempting to trigger looping TreeMap.WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by ConcurrentTreeMapLoopReproducer (file:/home/knuckles/projects/treemap-blog/) to field java.util.TreeMap.root
WARNING: Please consider reporting this to the maintainers of ConcurrentTreeMapLoopReproducer
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
..............
Was able to reproduce loop in map: 10 --left--> 5 --right--> 14 --left--> 10

What does this mean? It means that internally, the tree has formed a loop.^[2] Here’s how this one specifically looks like:

And here’s a very simple animation of what would happen if you were to call get(9) on such a tree:^[3]

Another way to cause an infinite loop is to uncomment the line containing //brokenMap.values().toArray();. This operation attempts to iterate the map, and gets stuck on the loop forever.

As always, be careful when combining concurrency and mutation. And thanks to my awesome colleague Oli for the really interesting debugging session.

1. You may want to try increase the insertUpTo parameter or adding more threads if you’re having trouble reproducing the issue on your own machine.

2. It’s no longer a tree. Insert "not being in Kansas" joke.

3. Note that it’s not always possible to find a key k such that get(k) generates a loop. I leave as an exercise to the reader to discover why 😁.

TIL: Java hides lambda frames in stack traces

Thu, 21 Jun 2018 00:00:00 +0100

While playing around with Java stack traces today, I noticed something that I had never noticed before: lambda frames do not show up in stack traces!

For instance, consider the following pre-Java 8 example:

public class VisibleLambda {
  public static void main(String[] args) {
    foo(new Runnable() {
      public void run() {
        bar();
      }
    });
  }

  static void foo(Runnable lambda) {
    lambda.run();
  }

  static void bar() {
    throw new RuntimeException();
  }
}

In the main method, we create an anonymous inner class that implements Runnable and calls bar when run.

The resulting output for this program is as expected:

Exception in thread "main" java.lang.RuntimeException
        at VisibleLambda.bar(VisibleLambda.java:15)
        at VisibleLambda$1.run(VisibleLambda.java:5)
        at VisibleLambda.foo(VisibleLambda.java:11)
        at VisibleLambda.main(VisibleLambda.java:3)

Checks out: main calls foo, which then calls the Runnable::run method (here implemented by a class automatically named VisibleLambda$1), which then calls bar. So far, so good, and this matched my understanding of how this works together.

But consider now what happens when we switch to using a Java 8 lambda:

public class HiddenLambda {
  public static void main(String[] args) {
    foo(() -> bar());
  }

  static void foo(Runnable lambda) {
    lambda.run();
  }

  static void bar() {
    throw new RuntimeException();
  }
}

…and the output is:

Exception in thread "main" java.lang.RuntimeException
        at HiddenLambda.bar(HiddenLambda.java:11)
        at HiddenLambda.lambda$main$0(HiddenLambda.java:3)
        at HiddenLambda.foo(HiddenLambda.java:7)
        at HiddenLambda.main(HiddenLambda.java:3)

Did you see it? Two interesting things happened here. One is that a new method named lambda$main$0 appeared in the HiddenLambda class. The other is that our Runnable is gone — nowhere on the stack we can see a run method being called, although it is definitely there.

So what’s the lambda$main$0? Using javap -p -c HiddenLambda we can see that it contains the code to our little lambda:

public class HiddenLambda {
  private static void lambda$main$0();
    Code:
       0: invokestatic  #7                  // Method bar:()V
       3: return
}

So where’s our Runnable? Here the plot thickens. It turns out that Java 8 introduced a new, internal-only magic annotation called @java.lang.invoke.LambdaForm$Hidden. This annotation is used in many methods used by lambdas, and in the lambdas themselves.

When the JVM is reading Java classes containing methods that are tagged with this magic annotation, it sets an internal flag on each method predictably called _hidden. Then, quite simply, in the code implementing Throwable::fill_in_stack_trace this flag is checked and any methods tagged with it are not included in the stack trace.

After reading a bit more of the source code, I’ve discovered that behavior can be controlled with command-line options: -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames.

So finally, here it is in action:

$ java -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames HiddenLambda
Exception in thread "main" java.lang.RuntimeException
        at HiddenLambda.bar(HiddenLambda.java:11)
        at HiddenLambda.lambda$main$0(HiddenLambda.java:3)
        at HiddenLambda$$Lambda$1/791452441.run(<Unknown>:1000000)
        at HiddenLambda.foo(HiddenLambda.java:7)
        at HiddenLambda.main(HiddenLambda.java:3)

My thoughts on, and how I approach code reviews

Sun, 08 Apr 2018 00:00:00 +0100

A few weeks back while I was having very interesting conversations with colleagues about code reviews I sat down and wrote some topics on how (and why) I take them on.

There are already a lot of awesome articles online on what you should be on the look out when reviewing code — such as this great one by thoughtbot — but my objective on this exercise is to focus on improving the code reviews themselves, not on specific code patterns.

Furthermore, most of my notes below are focused on how I like to approach them from the submitter side---not the reviewer!

So, without further ado, here are my thoughts on code reviews, in easy-to-digest bullets:

Part I: Before submitting a review

1. Commits tell a story

The more complex the change, the more important is to tell a story
Commits and commit messages SHOULD explain the why in addition to the what
- Aimed at other team members and your future self
- Can someone explain why in 6 months by reading your message and commit diff?
If commit is not interesting to the story, feel free to squash it
- For instance: "fix typo in variable name"
- Be careful about squashing and rewriting commit history AFTER code review starts ➡ may be hard for reviewer to follow
Feel free to rewrite the way you tell the story before you open the code review
- Don’t worry too much about it during development on your machine

2. Review your own code

You have the most context on the change
Be critical:
- Is this part really needed?
- What would you improve (even if not right now)?
- Are there unrelated changes?
- Are there accidental changes?
  - (Hello temporary files, whitespace and random IDE changes)
  - .gitignore (which can be global for a number of repos!) is a great help here
Great way to avoid minor comments and to avoid discussion getting too lost in them

3. Have a computer review your code

All tests green
Coverage
Linting
Other tools?
- Mutation testing?
- … what else?
But! Be careful about impact during development. These tools should not impede debugging/experimentation and only need to be clean/all green before the review is requested

4. Be mindful of the diff and diff noise

Be careful about renaming/moving lots of things, and then fixing one or two lines in the process:
- Consider renaming first, and then fixing (remember: tell the story)
- Consider making separate code reviews
- Consider how easy is it to review a 2k line code review with renames + some sprinkled changes VS…
  - Code review #1: 2k lines changed, only renames/moves made with IDE or search and replace; no other changes
  - Code review #2: 10 lines changed, "fixed foo"
But! Don’t be afraid of constantly improving codebase
- Be careful of "let’s not touch this to avoid diff noise". Do touch it! Just submit it on a separate code review or commit! 😄

5. Be mindful of the reviewer’s time/effort

Avoid skipping steps that you could have done (such as re-running tests) and relying on the reviewer to pick it up
- Unless agreed in advance: Team may decide to help unburden the submitter by being more active and involved in the review (may even pick it up and carry on in her stead)

6. Can you feature flag it?

Working on your own branch for a long time is a pain: there’s going to be conflicts, painful rebase operations, concerns about merge/deployment timing, etc
So, can you feature flag it?
- Having new code disabled allows you to break something down into small incremental steps without impacting code stability
- Smaller reviews, merge often
- Only enable when ready and tested
It’s ok to develop in a branch, if they are short-lived
- Definition of short-lived left to the reader and team ;)
Be careful about leaving behind old code after enabling feature flag
- Feature flags should be short lived and have clear objectives/targets for when they should be removed. Otherwise they are probably options
- Consider opening a pull request that removes the feature flag that will stay open and only rebased/merged down the line — it’s a great exercise and often reveals hidden dependencies on the old code

7. Be comfortable enough to press the merge button immediately

If not, say it. Call it RFC/WIP. Tell people what’s missing, and what you want feedback for
Otherwise people will (and should) assume you’re happy with the current state of the work, and that it does what you set out to do

8. Remember that a code review is not something you do after you finish a task

It ➡ is ⬅ part of the task.

Part II: During a review

9. Continue telling a story

New commits should still tell a story
- Avoid big "fix issues pointed out during review" commits
- Although a small "fix typos/improve naming" is ok too

10. Lengthy reviews with lots of churn: upstream issue?

Code review is a great safety net. Sometimes it catches bigger unexpected oversights from previous steps
If code review is taking long and a lot of changes are being discussed:
- Maybe the design should have been fleshed out better before development?
- Maybe some mentoring / pairing was needed?
It’s ok for this to happen. Quite insightful to look at why and try to improve for next time

11. Clarify if feedback is blocking or not

This is both on the reviewer and on the submitter:
- Is proposed change a must-have?
- Can some addition be pushed to a separate code review?
- Is it just a suggestion?

12. It’s ok to go back!

Feel free to close/split/cancel your code review, if you believe it will have a positive result, such as speeding up the review process

13. Answer reviewer’s questions with code

From the Google Testing Blog: "Don’t just reply --- make the code easier to understand or add a comment. Someone else is going to have the same question later on."

14. Can a reviewer’s comment apply elsewhere in this code review?

A useful comment/insight quite often may apply to multiple places in the same code review
- Do a quick pass over your diff and check if you fixed all similar instances

Part III: During a review — for reviewers

15: Build it in your head

Go beyond "looks ok"!

16: Imagine how you’d make this change

Be careful not to get too attached to your opinion though. But do compare it with solution you see

17. Prioritize code reviews

Try to review ASAP
Try to reply to feedback ASAP
Timebox if needed

Part IV: Closing the review

18. Trust your team

Place trust on your team-mates! If remaining changes are small enough, it’s ok to pre-approve the code review and rely on the submitter to push through the final version
- Instead of requiring a new re-review just for small things
If the submitter decides to do bigger changes, it falls on her the responsibility to call them out and ask for a re-review

19. Shared responsibility for 👍

Be comfortable about giving your "LGTM 👍", pressing merge, and then going home while you’re on call
- It’s everyone’s responsibility to make sure the change is in good shape
But… Do balance this out with getting shit done: It’s ok to 👍 even when there are concerns on something WIP as long as this is clearly identified, communicated, and of course there is no negative impact on the users of the service/codebase

20. Remember that "it’s not done until it ships"

— Steve Jobs

21. Guidelines, not rules

The above ideas are guidelines that support
- Communication
- Learning
- Collaboration
- Speed
- etc…
The end goal is delivering a better product through engineering excellence
But do skip/ignore/replace any ideas that are not having a positive impact towards our team’s goals

22. Team decides best practices

It’s up to all members of the team to decide what to allow or not, decide what we want to enforce a set of rules (and which rules) or not, etc

Is this ok…? Or, spotting unsafe concurrent Ruby patterns

Wed, 31 Jan 2018 00:00:00 +0000

The past weekend I had the enormous pleasure to speak at the Ruby on Ice 2018 conference in Tegernsee, Germany.

Figure 1. All Ruby conferences should have a view like this 😁

I decided to give the talk I wish I had seen about four years ago before I joined Talkdesk, on a number of gotchas and common mistakes one can do when working with Ruby and concurrency.

You can find the video for this talk, as well as the slides on this newer post.

Concurrency is an extremely powerful technique that should be part of every Rubyist’s tool belt. But when a lot of people pick up tools such as puma, concurrent-ruby or even JRuby, they are at the same time thrilled by all the power that threads and concurrency gets them, and afraid for the day when a concurrency bug will come and chew their arm (or service) off.

But what do we normally mean when we talk about a concurrency bug? What do they look like? And how do you fix them, preferably without giving up performance or readability? In this talk, I will show examples of Ruby patterns and techniques that lead to unsafe behavior in the presence of multi-threading, be it in MRI or JRuby. I will then discuss how they can be spotted, why they are problematic, and propose safe alternatives.

Lightning Talk - Warm-Blanket: Goodbye crappy after-boot performance

Sun, 07 Jan 2018 00:00:00 +0000

Back in September, at the EuRuKo 2017 Ruby conference, I decided to submit a lightning talk on the warm-blanket gem.

If you’re curious for a bite-sized introduction and motivation on why you should care about it, you can find the presentation and slides below 😁

persistent-💎: a new ruby gem for beautiful immutable data structures

Wed, 03 Jan 2018 00:00:00 +0000

After a few weeks of work, I’ve just released version 1.0 of my new gem: persistent-💎!

The objective of this gem is to make programming with immutable data structures in Ruby as joyful and frictionless as using the built-in Array and Hash classes. So easy, in fact, that using immutable structures becomes the norm, rather than the exception.

Ruby has no immutable data structures in the standard library, but it is flexible enough that we can add such functionality as a library, and disguise it so it almost looks like the built-in data structures.

For instance, with persistent-💎 you can create:

Arrays: my_array = a💎[1, 2, 3]
Hashes: my_hash = h💎[key1: 'foo', key2: 'bar']
Sets: my_set = s💎[:sephiroth, :kills, :aeris]

Using an emoji as part of the gem’s api was an interesting challenge, but with some care it’s possible to support Ruby 1.9.3 to 2.5.0, and JRuby 1.7 and 9.x, although the latter have some known bugs with unicode handling.

Furthermore, this gem integrates with the concurrent-ruby and hamster gems, so you can easily convert back and forth between instances of these libraries, so you can use the best tool for the job.

This was a very fun project, and the git history reveals that it took a bit more than I expected to get it just right.

So… go forth and use it. Feedback is very welcome!

asciidoc: an awesome markdown alternative

Sun, 22 Oct 2017 00:00:00 +0100

Yesterday while reading through the twitters, I came upon a reference to a markup format called AsciiDoc which I had never heard about before.

Oh wow. Just read up on asciidoc and asciidoctor and woooow. This just made my life. Mind. Blown.
— Ivo Anjo (@KnuX) October 21, 2017

I started reading about both AsciiDoc and the AsciiDoctor tool and they completely blew my mind, so I immediately decided that I had to write a blog post about it --- Using AsciiDoc, of course!

Awesome AsciiDoc+AsciiDoctor features

So if you already are comfortable with Markdown, why should you care?

Here are some of the features that really impressed me:

Generating a table of contents: A table of contents can be automatically generated based on your document structure. You can control where a ToC is placed, how many subsection levels to include, and even its title.

Including files in a document. You can use this to:

Split up your document into multiple files and then include them all to create a single final output
Include data from an external csv and render it as a table

Including verbatim source code from source files. You can even slice the file by tags or by lines.

For instance, here’s the source code for this itemized list thus far, directly embedded from the post source file (not copy-pasted!):

* http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#include-files[Including files in a document]. You can use this to:

** http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#include-files[Split up your document into multiple files and then include them all to create a single final output]

** http://www.methods.co.nz/asciidoc/newtables.html[Include data from an external csv and render it as a table]

** Including verbatim source code from source files. https://mrhaki.blogspot.co.uk/2014/04/awesome-asciidoc-include-partial-parts.html[You can even slice the file by tags] or https://mrhaki.blogspot.co.uk/2014/08/awesome-asciidoc-include-only-certain.html[by lines].

Callouts in source code:

def foo
  begin
    raise 'Hello, world' # (1)
  rescue => e
    puts 'Rescued!' # (2)
  end
end

This will raise a StandardError
This will stop the exception from propagating

Note/tip/warning/etc blocks
Counters: Each (1) time (2) you (3) include (4) {counter:some_name} a number gets printed and incremented.
Footnotes ^[1]
^Super and _subscript text
Custom substitutions! You can define a substitution :version: 1.0.0 and then use it in links https://rubygems.org/gems/warm-blanket/versions/{version} and in the text “Latest stable version is {version}” and then they’ll get automatically replaced:
- Latest version is 1.0.0, link https://rubygems.org/gems/warm-blanket/versions/1.0.0
You can add comments without needing to cheat by using html ;)

Using AsciiDoc

AsciiDoc documents use the file extension .adoc. Most text editors already ship with or have third-party plugins to perform syntax highlighting.

But yeah, so there’s lots of fancy features, but Markdown is already everywhere… isn’t it?

The best news is that AsciiDoc is the most widely-supported format you’ve never heard about:

You can use it on GitHub and on GitLab. Yes, really: https://github.com/Talkdesk/warm-blanket/blob/master/README.adoc
You can use it with the jekyll website generator (and many others). In fact, you’re looking at jekyll-asciidoc's output right now!
You can use it together with gitbook to write awesome documentation
You can convert it to html, docbook, and many other formats
You can use asciidoctor’s markdown compatibility to ease your transition
You can convert your existing Markdown content to AsciiDoc automatically
You can edit it with live preview online. And it even supports collaborative editing, woohoo!

Go forth and explore!

I hope I was able to share some of my enthusiasm about AsciiDoc with you!

If you want to learn more, I suggest starting with:

1. This is an example footnote!

Why I always use attr_reader to access instance variables

Wed, 20 Sep 2017 13:46:00 +0100

Ruby’s attr_reader method can be used to automatically generate a “getter” for a given instance variable.

In simple terms, doing

attr_reader :engine

is the same as writing

def engine
  @engine
end

I’ve adopted a programming style where I always try to use attr_reader to access instance variables (or getters, if you prefer to call them that 😁). I’ve been asked about the reasons that led me to adopt this style in several PRs, so I wanted to write a quick post motivating my choice.

As a ~~driving~~ running example, I will use the following class to represent a car:

class Car

  attr_reader :owner
  attr_reader :license_plate

  private

  attr_reader :engine
  attr_reader :gearbox

  def initialize(owner:, license_plate:)
    # ...
  end

  public

  # ...
end

💡 Note: An earlier version of this post put the public before the initialize. In practice, doing this doesn’t affect the initialize (try it out for yourself!); but to make it even more clear, I’ve moved the public below that definition – thanks Victor Goff for an insightful discussion on this matter.

And here’s my reasoning:

Placing all attr_readers at the top of the class

This serves as documentation: You can open up a class and immediately spot what its internal state is.

Furthermore, if your code is well-behaved and there’s no attr_writers or attr_acessors, you can quickly know if a class is mutable (its internal state can change during its lifetime) or immutable (its internal state cannot change after initialization — note that this only covers the object itself, and not the objects it references, e.g. if the variable points at an unfrozen array).

By following this simple code discipline, you can get a lot of useful information at a glance.

Using the attr_readers to access instance variables from inside the class

This helps avoid typing mistakes. For instance, consider we add the following method to our Car class, but mistakenly add a typo while writing it (e.g. @eNgine instead of @engine):

  def start
    @gearbox.neutral
    @eNgine.start
  end

What happens when we try to run our code?

$ ruby car.rb 
car.rb:20:in `start': undefined method `start' for nil:NilClass (NoMethodError)
        from car.rb:24:in `<main>'

“What? Why is my engine nil?” you may ask yourself. And off you go on a wild goose chase trying to hunt down why your engine was not correctly initialized because you haven’t noticed that there’s a typo on your start method.

So instead let’s not access the instance variables directly, but let’s use the methods that the attr_reader created:

  def start
    gearbox.neutral
    eNgine.start
  end

And what happens when we run this version?

$ ruby car.rb 
car.rb:20:in `start': undefined local variable or method `eNgine' for #<Car:0x000000c9d9522d50> (NameError)
Did you mean?  @engine
        from car.rb:24:in `<main>'

Our output is a lot clearer: there’s no eNgine declared and “did you mean?” engine. You immediately spot your typo and move on.

The usual advantages of using a getter

When you use a method to access your instance variable, it becomes a lot easier to later refactor it, without needing to update all the places where it is used.

For instance, consider that we wanted to lazily initialize an engine whenever one is not provided when our car object is created. We can easily change our

attr_reader :engine

into

def engine
  @engine ||= EngineFactory.create
end

Done! This saves us from hunting down usages of @engine in our class and its subclasses.

…Even for private instance variables…

Because all of the advantages above are applicable to instance variables that are not exposed to the outside of the class, I recommend using attr_reader for these variables too, even if you would not usually do so.

Introducing the WarmBlanket gem

Sun, 20 Aug 2017 10:00:57 +0100

Optimizing runtimes are a very hot topic for Ruby development right now: Historically, both JRuby and Rubinius dynamically optimized Ruby code as they ran it, but soon they will soon be joined by the likes of TruffleRuby, ruby+omr, mjit, llrb and topaz.

Furthermore, it’s common for Ruby web services to lazily load classes and open connections to dependent systems. This allows for faster system start-up time, and reduces memory usage: unused code is not loaded, and unused connections are not started nor kept active.

Dynamic optimization and lazy start-up techniques when starting a web service have a big downside: When a Ruby web service boots up, it will take some time for the service to reach peak performance. In my own experience, MRI — the most commonly-used Ruby runtime — takes several seconds to hit peak performance, but more aggressively optimizing runtimes, such as JRuby, take several minutes to reach their highest-performing state.

This period of reduced performance, if ignored by service operators, is normally observed by service clients as a spike in request latency, with timeouts sometimes kicking in. (Not very unexpectedly, this issue is not specific to Ruby.)

While working at Talkdesk on supporting new web services written using JRuby, I decided to tackle this problem by creating a new gem: WarmBlanket.

WarmBlanket is targeted at deployment environments where services can be given a warm up period before they start to receive client requests, such as Heroku’s preboot or Kubernetes’ readiness probes.

During the warm up period, WarmBlanket connects as an http client to the web service and repeatedly performs a number of pre-configured common requests. By exercising most endpoints, all needed code is loaded, database connections are started, and dynamically optimizing runtimes can optimize the code paths being exercised.

As a result, when a service starts to receive production traffic, it is at or near its peak performance, and thus ready to provide an awesome service to its clients.

If this sounds good, you can find WarmBlanket on rubygems and on github. All feedback, issues, and contributions are welcome!

Ninjas’ guide to getting started with VisualVM

Sat, 12 Aug 2017 23:44:31 +0100

VisualVM is a free Java/JVM tool that ships with most Oracle JDK/OpenJDK installs (if you’ve used Erlang’s observer previously, it’s a similar tool). It can be used to both profile and debug applications running on the JVM—including Java, JRuby, and many others.

I’ve mentioned it several times before on this blog as part of my JRuby voyages, as it’s my go-to tool to start investigating any kind of issue in a JVM application.

Recently, I’ve written a thorough guide on VisualVM’s features (including a special section with cool JRuby goodies) for Talkdesk’s Engineering Blog. You can check it out embedded below or at https://engineering.talkdesk.com/ninjas-guide-to-getting-started-with-visualvm-f8bff061f7e7.

What is VisualVM?

VisualVM is a free Java/JVM tool that ships with most Oracle JDK/OpenJDK installs (if you’ve used Erlang’s observer previously, it’s a similar tool).

This tool can be used:

in development: connecting to applications running on the local machine and on docker
in test environments: connecting to live Heroku dynos or AWS systems
in production environments: connecting to live Heroku dynos or AWS systems (with important caveats, discussed below in the Debugging with VisualVM section)

VisualVM can be used with all JVM languages (Java, JRuby, Kotlin, Scala, …). It works at the VM layer which means that high-level concepts from other JVM languages are missing, and instead you’ll see their “under the hood” representation. But don’t let this scare you off, you can still get plenty of useful information, even with this limitation.

This guide is divided into several parts:

Getting VisualVM: A simple getting started guide.
Connecting VisualVM to a running application: How to get VisualVM talking to your application, locally or otherwise.
Debugging with VisualVM: What you can do with VisualVM.
Recommended plugins: Turbocharge your VisualVM install.
JRuby goodies: JRuby-specific tools and techniques.
Further exploration: Other suggested awesome JVM tools.

Getting VisualVM

If you have the javac command, you should also have visualvm or jvisualvm. As of this writing, the latest version is 1.3.9, which I recommend you use.

If you don’t have the latest version (or any version at all), go to VisualVM’s website and make some magic happen.

Connecting VisualVM to a running application

Local application running natively

This is a simple one step process.

Step 1: Go into the applications tab. There you will find your application.

Local application running inside Docker

You’ll need to enable the VM remote management extensions by defining an environment variable and expose the management port outside of docker.

Step 1: Go to your docker-compose environment and add the JAVA_TOOL_OPTIONS environment variable with the following configuration:

JAVA_TOOL_OPTIONS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=localhost -Dcom.sun.management.jmxremote.rmi.port=9010

Step 2: Then, when running your docker container, expose port 9010 to your local machine:

$ docker-compose run -p 9010:9010 <your service>

Step 3: Now you’re all set to connect using VisualVM. Go to File > Add JMX Connection… Use localhost:9010 as a target. Don’t touch any of the other options. Then, press OK. A new “localhost:9010” entry should appear on the applications list. Double-click it to get the magic to happen.

(See also https://medium.com/@logbon72/this-was-quite-helpful-34b56ab7b175 that lists a few extra tweaks to get docker to work)

Remote application running on Heroku

Step 1: Start by installing the heroku-cli-java plugin for the Heroku cli. This only needs to be done once because it adds to the Heroku cli, not to any specific app.

$ heroku plugins:install heroku-cli-java

Step 2: You’ll also need to add the exec buildpack to your Heroku application. This will install some extra tooling into the deployed container image that we’ll use to access the remote dyno.

Step 3: As Buildpack changes are only applied after re-deploying, you now need to re-deploy your application.

Step 4: AFTER RE-DEPLOYING YOUR APPLICATION, *ahem* you can now use the following command:

$ heroku java:visualvm --app <your heroku app> --dyno <your dyno>

If it all goes well, VisualVM will pop up and start connecting. You may see a warning about the connection being insecure which you can ignore. The connection process may also take a while (around 10–15 seconds).

Note: If you do not specify a dyno, Heroku will default to web.1 which will net you a “Could not connect to dyno!” error on applications without web dynos.

Heroku connection gotchas

1. VisualVM error when connecting to remote dyno

There goes the neighbourhood

If you get a “Cannot connect to <foo> using <some url>” error message, manually configure your proxy settings as shown below:

Note: You’ll probably want to undo this setting next time you want to connect to a docker container or a local application.

Debugging with VisualVM

In this section I’ll go into some of the investigation and debugging tasks you can do with VisualVM. Note that if your VisualVM does not look like mine, you’re probably missing one or more of the plugins I have installed. See the next section for an overview of them.

Production caveats:

Be wary about using these tools and techniques in production.

Some of them can have a big impact on the performance and responsiveness of your running system, thus you may end up making an ongoing problem even worse. I will attempt to indicate where you should be extra careful when using certain mechanisms. If you’re unsure, always plan to monitor closely, and preferably pair on the work before going all rambo into production.

Monitor panel

This is actually not the same picture as the one in the introduction

The Monitor panel presents at-a-glance info on the overall state of the VM:

CPU: usage as a percentage of total machine resources, e.g. a fully-loaded thread will be at 25% on a four-core machine
Heap: the main memory arena where objects and arrays are kept
Metaspace: a separate memory arena where classes and other JVM metadata are kept
Classes: number of classes loaded on VM (includes automatically-generated classes)
Threads: number of threads in the VM. Live threads are daemon + non-daemon

The “Perform GC” button triggers a full garbage collection.

The “Heap Dump” button requests that the JVM take a heap dump. BE CAREFUL: Taking a heap dump means stopping all application threads while a possibly multi-gigabyte file is written. Your Java code will be suspended until this process finishes. One caveat of this functionality is that it only works seamlessly when VisualVM is accessing an app running natively on your machine. If you’re connecting to a Docker container or Heroku dyno, you’ll be asked where to save the file remotely, and you’ll need to manually transfer the heap dump file to your local machine and open it with “File > Load…”.

Update: On Heroku you can use the following command to take a heap dump and automatically download it:

$ heroku java:jmap --app <your heroku app> --dyno <your dyno>

Thread panel and monitoring thread state

Whoa! It scales!

This panel gives a view of the state of every thread in your application. If you expect your system to be fully loaded (e.g. during load testing) and instead of seeing all or mostly running threads (green), you get parking (orange), waiting (yellow), or blocking on a monitor (red), those are strong indicators that something may be off.

From this panel you can also ask for a Thread dump: a listing of the stack traces of all running threads. Note that for non-Java JVM languages, these stack traces will probably not map 1:1 to the methods you wrote on your IDE (e.g. you’ll be looking at how that language gets translated to JVM bytecode; see below for some language-specific notes).

Navigating a heap dump

A heap dump is a snapshot of the state of the Java object/array heap. On the Summary pane you can see information on the dump and the stack traces at creation time. On the right you can immediately search for large objects on the heap.

On the Classes pane you can see a summary of the state of the heap, broken down by class: name, number of instances, and size occupied by all of them. You can also press the “Static Fields” button to navigate into the contacts of the classes’ static fields.

When you double-click on a class, you’ll be taken to the Instances pane, where you can drill down into each instance of that class, individually.

On the left pane, you can select any one of the objects you want to browse. In this case I’ve picked a java.lang.String containing my OS. On the top-right, you can see the object’s fields: the String is backed by a char[] containing the characters themselves.

In the bottom-right pane you can see all references to the object. This is a navigable view of the references that are pointing at the object, and we can see that our example object is referenced both in the value field of a HashMap$Node instance, and in the str field of a ProcessEnvironment$Value instance. Interestingly, this also lists references from local variables that are on the stack of currently-active threads.

Finally, the OQL Console. This provides an SQL-like language for finding things on the heap — for instance, find all strings containing foo. It’s very powerful, so feel free to explore it.

Sampler panel: A simple sampling profiler

A sampling profiler works by taking thread dumps of the system at some regular interval and reporting on where it observes time being spent. This has the advantage of having a smaller performance footprint than a tracing profiler (introduced below), but it is therefore less accurate.

You can control the sampling frequency and how often VisualVM updates the visualization. You can either profile CPU or Memory.

Key Takeaway: Don’t run a profiler in production.

CPU Sampling

CPU sampling shows you where time is being spent on the application. The key is to know how to read the information:

Self time: How much time the profiler observed the listed method spent executing the method’s own code (e.g. if the method calls another method, it will not include that time). Note that packages configured as “not profiled” (as seen in the first picture of the section) are counted as “a method’s own code”. In practice, this means that if, for instance, you are doing a lot of string manipulation, time spent in JDK string code will be counted as self time (because JDK classes are configured as “not profiled” by default).
Self time (CPU): How much CPU time was actually spent by the method. For instance in the image above, we can see a mostly-idle system that apparently spends a lot of time executing a small number of the methods. In reality, little CPU time is actually spent, because the code is just calling Thread.sleep().
Total time: Sum of all time “spent” with that method active on the stack. E.g. it also includes time in methods called by that method.
Total time (CPU): How much CPU time the total time actually corresponded to. Like self time (CPU), a method may be active on the stack but the thread it lives on may actually be sleeping or waiting on I/O, e.g. no CPU is actually being used.

In the Thread CPU Time sub-panel you can view how much CPU time is being spent by each thread. This allows you to inspect CPU time since the sampling started (Thread CPU Time [ms]) and instantly (Thread CPU Time [ms/sec], on the far right).

You can also take a Snapshot of the current data, which will open the Profiler Snapshot tab. This allows you to navigate a call tree visualization that includes both total time and total time (CPU), grouped by thread. The Hot Spots tab below also includes a snapshot of the live table info that the sampler shows.

Memory Sampling

The memory sampler allows you to see a live view of the distribution of objects of the heap, and their footprint.

The Per thread allocations tab further breaks down allocation information per-thread, showing total allocated bytes and allocated bytes per second. This allows you to see which threads are more active in creating new objects.

Profiler panel: A simple Tracing Profiler

A tracing profiler works by modifying loaded bytecode in the JVM, adding counters to all methods so that it can accurately measure which methods are called and how much time is spent executing them. Note that this has a huge overhead, and the resulting profile may not reflect the performance of your application at all.

Key Takeaway: Don’t run a tracing profiler in any kind of non-local setup.

Other than that, the CPU part of the tracing profiler is very similar to its sampling counterpart.

Note for JRuby: The CPU part of the tracing profiler seems to break due to the JRuby’s use of automatically-generated bytecode; I was not able to get it to work beyond very simple examples.

The memory tracing profiler provides a lot more information than its sampling counterpart, such as object counts and how many GC generations they live for.

Furthermore, when you enable the Record allocations stack traces option, leave the profiler running and then take a snapshot, you’ll be able to explore the stack traces that led to objects being allocated by right-clicking a class and selecting Show allocations stack traces.

Recommended plugins

Out of the box, VisualVM already includes quite a lot of functionality, but if you go to Tools > Plugins you can get even more great tools. Below is a quick overview of them.

Visual GC

Includes detailed information on GC status, timings, and usage of various memory regions.

Memory Pools

Detailed metrics of all JVM memory regions, including things such as the code cache.

Threads Inspector

Adds an extra panel to the Threads tab where you can see the stack traces of the chosen threads.

VisualVM-MBeans

Adds an extra tab that allows browsing and interacting with management beans. Management beans are a mechanism exposed by JVM and application components where they can expose their own metrics, configurations, and even allow live modification of some settings.

VisualVM-BufferMonitor

Adds a tab to monitor the JVM’s buffer pools. Note that like other pools discussed above, these are separate from the normal object heap.

VisualVM-JvmCapabilities

Adds a small panel listing available metrics and monitoring capabilities for the JVM being accessed.

OQL Syntax Support

Adds syntax highlighting, indentation help and autocomplete to the OQL language used to perform queries on heap dumps.

Tracer-* Probes

Enables the Tracer tab, adding other metrics that can be monitored and graphed.

JRuby goodies

The JRuby Management Bean

When using the VisualVM-MBeans plugin you can also enable the JRuby management bean by adding the -Xmanagement.enabled=true option to your JRUBY_OPTS environment variable or to the JRuby command line directly.

This management bean exports a number of very useful operations under the org.jruby > Runtime > … > Runtime item:

You can get a Ruby-level thread dump using the threadDump operation. This displays a stack trace as what you’d expect to see on MRI, instead of the raw Java one you can get with the Thread dump option in the Threads tab.

You can also (and obviously be very careful about what you do here) send Ruby code to be eval()’d by JRuby using the executeRuby operation. You may even want to do something like require "pry"; Pry.start. Use your imagination 😀.

Reading raw JRuby stack traces

Similarly to how a lot of JVMs work internally, JRuby starts off interpreting your Ruby code, and as it warms up and detects hot spots it JITs your Ruby code into automatically-generated Java classes, which function similarly to callables, and contain your Ruby methods (or parts of them). All of this happens behind the scenes, but when you ask for a Java-level thread dump, you’ll see this process in action.

This means that by default in your stack trace you’ll probably find a mix of JRuby interpreter methods and the JRuby JIT classes, which looks somewhat like this:

Pardon for the raster nature of the example

After the JIT callable is generated, the class/method name is rather ugly, but it accurately tells you what code is running, and where it came from.

For debugging reasons you may want to force JRuby to compile every Ruby method into one of these callables, rather than doing this only for hot methods. You can do so by adding the -Xcompile.mode=FORCE option to your JRUBY_OPTS environment variable or to the JRuby command line directly. This has the advantage of allowing you to see every single Ruby method represented on the Java stack — instead of seeing some of the methods only as JRuby interpreter method calls — but has a memory and performance penalty.

Analyzing JRuby heap dumps

RubyObjects all the way down

By default, all Ruby objects are represented in the Java heap as instances of the class org.jruby.RubyObject. This means that if you’re after a Ruby object memory leak, this will not help you. You could use OQL to try to identify classes and whatnot, but there’s actually a simpler way:

If you add the -Xreify.classes=true option to your JRUBY_OPTS environment variable or to the JRuby command line directly, JRuby will generate JVM classes inside the rubyobj package corresponding to each Ruby class (with matching Ruby namespace too). Unfortunately, this feature has some known bugs; a workaround is included in the issue report, but you’ll need to patch your JRuby instance, which is a bit more involved.

Further exploration

Here are some commercial and free tools you may want to take a look at, if you’re interested in VisualVM:

adopting tls

Tue, 02 May 2017 23:01:59 +0100

Just a quick note: If you can read this, it means this blog has finally left the internet stone age and is now being successfully served using https/tls via amazon cloudfront.

Thanks to Oliver Pattison for his great guide on how to do so.

Join us! We have cookies!

P.s.: Next step is getting HSTS and other recommended security headers going.

rubies: a look at ruby's shiny future

Mon, 17 Apr 2017 00:00:00 +0100

I’m a huge fan of the Ruby programming language, but in terms of implementation Ruby still lags behind other dynamic languages such as Javascript, which have powerful optimizing runtimes capable of delivering blazing performance.

Yet I think Ruby in 2017 is closer to that goal than ever: it seems like everyone in the Ruby runtime game is looking at techniques such as JIT compilation and speculative optimization.

Recently, on the 7th of March, I gave a presentation at the 4th edition of the [sardines.rb](https://www.meetup.com/sardinesrb/) meetup on the future of Ruby implementations in 2017 and beyond.

You can find the video and slides of my presentation below, enjoy!

quickies: heroku exec and deploying jruby

Sun, 19 Mar 2017 10:23:00 +0000

heroku exec!

A few months back on my “another round of jruby goodness” post I wrote about a heroku buildpack that, combined with a reverse proxy like ngrok would allow connecting to a heroku node, and that could even be used to open up Java VisualVM and connect to it, live.

This week I was pleasantly surprised to see heroku introduce this functionality out of the box with the heroku exec add-on.

After setting up the add-on, opening up VisualVM on a dyno for monitoring a JRuby or Java application is now as simple as

$ heroku java:visualvm --dyno web.1

A big 👍 to heroku for this feature!

deploying jruby elsewhere

If heroku isn’t your thing, my colleague Daniel Gomes has also been experimenting and writing about deploying a JRuby web application on the cloud using Packer and Terraform.

An interesting read!

why you should be using jruby in production

Thu, 16 Mar 2017 00:19:39 +0000

On February 23rd I gave a presentation at the Fullstack LX meetup detailing why you should use JRuby and how it helped my team at Talkdesk identify complex bugs and hit our performance goals.

You can find the presentation and slides below, enjoy!

Update: Video went down and I did not have a copy 😢. I’ll update this if I can restore a copy. (Or you can just invite me over to your meetup to present it live 😅)

benchmarking jruby invokedynamic with a production application

Sun, 29 Jan 2017 22:55:02 +0000

As you read JRuby blog posts and other resources around the web, you may find references to JRuby’s compile.invokedynamic option, that as of 9.1.7.0 continues to ship turned off by default.

So, why is it off? I asked the JRuby developers and here’s what they had to say about it:

@KnuX @tom_enebo Primarily startup and warm-up time: both increase. It has improved somewhat in Java 8.
— Charles Nutter (@headius) January 26, 2017

@knux @headius It is only for warmup reasons. Eventual performance is generally better (or at least as good).
— tom_enebo (@tom_enebo) January 26, 2017

…and here’s what Joe Kutner’s “Deploying with JRuby 9k” has to say about it:

The invokedynamic instruction promised great performance improvements for JRuby, but it turned out to improve only a few specific cases. […] for now, JRuby keeps this feature off by default. You may find it worthwhile to test your application with invokedynamic turned on. It’s possible you’ll see some performance gains depending on the kind of logic you have in your app.

So in some benchmarks it seems rather relevant, but others suggest than on production applications it may not be the way to go. So which is it?

To test it out, I decided to benchmark it with one of Talkdesk’s internal JRuby applications. This application (dubbed ciw) reads tasks from rabbitmq message queue, and communicates with another internal microservice in order to update or create new records based on the received data.

After warming up the application, I loaded 6000 tasks on the rabbitmq message queue and measured how long (in seconds) the application took to go through all the tasks and empty the queue. The tests were performed on a Core i7-6500U (2.5 GHz) with 8GB of RAM running Ubuntu Linux 16.10, and the JVM used was the Oracle Java(TM) SE Runtime Environment (build 1.8.0_121-b13) / Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode). The application was configured to use 16 threads to process tasks.

I tested four different configurations: both JRuby 9.0.5.0 and 9.1.7.0 are tested on their default configurations (compile.invokedynamic turned off) and with the option turned on.

The results are shown below:

Turning compile.invokedynamic on yields a 26% speedup for JRuby 9.1.7.0, shaving more than a minute from the time needed to execute the workload!

Furthermore, we can also see how JRuby performance has slightly improved in a year, between JRuby 9.0.5.0 (released in January of 2016) and JRuby 9.1.7.0 (released in January of 2017).

So what’s the verdict? If you’re not impacted by having longer start-up and warm-up times for your application, you should really be adding -Xcompile.invokedynamic=true to your JRUBY_OPTS or application startup scripts.

As for JRuby it may be time to enable this option by default again. Or at least rename it to something more awesome-sounding, like --production-booster ;)

Update, 11th May 2017: Recently, while I was benchmarking a web application using JRuby, I discovered a use case where code using compile.invokedynamic ran noticeably slower than when that option was disabled.

Turns out it was a bug, which the JRuby developers fixed awesomely quickly, making compile.invokedynamic again faster than the non-invokedynamic code path. So, if you find any such instances, do report!

pry-debugger-jruby gem now on rubygems!

Fri, 02 Dec 2016 09:14:32 +0000

As a followup from my psa: you can now debug with pry on jruby I have finally uploaded my fork of pry-debugger — the pry-debugger-jruby gem — onto rubygems!

The original post has been updated, but as a reminder, using it is as simple as adding

gem 'pry-debugger-jruby'

to your gemfile, and then starting pry on JRuby.

Feedback and issues are very welcome! :)

weekend hacking: enviado gem

Tue, 22 Nov 2016 09:03:57 +0000

On friday I started reading up on lyft’s recently-announced envoy proxy/communication bus/general awesome piece of kit.

Envoy can be used in many different ways:

As a reverse proxy in front of some service
As a service-to-service communication provider (including service discovery)
As a local proxy to some remote service

This last configuration piqued my interest, as I have been interested in solutions for doing circuit breaking ever since I learned of netflix’s hysterix library.

But retrofitting a circuit breaking onto an existing and rather diverse architecture can be a challenge. So, could envoy act as a low-level component that allowed circuit breaking, request resilience and service discovery to be slowly introduced into an existing architecture without much effort?

To try it out, I built the enviado gem. Enviado can be used to quickly start an envoy service along side a normal ruby application, and then make requests using envoy’s many features.

I’ve also developed a small example testing some of envoy’s resilience features:

And the resulting sample output:

Starting web server...
Doing 100 requests WITHOUT enviado...
Results: {500=>44, 200=>56}
Starting enviado
[2016-11-19 13:14:58.039][211][warning][main] initializing epoch 0 (hot restart version=3.2490504)
[2016-11-19 13:14:58.041][211][warning][main] all clusters initialized. starting workers
[2016-11-19 13:14:58.041][211][warning][main] starting main dispatch loop
Doing 100 requests WITH enviado...
Results: {200=>100}

This was just a quick hack, so feedback is very welcome. It currently ships only with an envoy binary for linux, but you can either run it via docker or PRs that add binaries for other platforms are very welcome!

P.s.: If you want to play with envoy, but prefer elixir, the awesome Tiago Sousa has got you covered with elixado. Kudos to him!

Addendum: If you’re interested on learning more about hysterix, I really recommend the Joker conf talk below by Tomasz Nurkiewicz:

jruby's Charles Nutter on the jvm as a language platform

Tue, 15 Nov 2016 19:45:00 +0000

I just finished listening to a recent episode of the Software Engineering Radio podcast:

SE-Radio Episode 266: Charles Nutter on the JVM as a Language Platform

In this podcast Charles Nutter—one of JRuby’s maintainers—discusses the relationship between non-Java languages that run on the JVM and Java/the Java platform; some history on JRuby and on the recently-released 9k version, and even touches a very interesting programming language which I’d never heard about: Mirah.

If you’re interested on the JVM platform or on JRuby, I really recommend this episode.

P.s.: Hopefully next time I’ll write something about Mirah ;)

peek and pick at mri's heap, part 2

Sun, 13 Nov 2016 19:47:44 +0000

In part 1 of this overview I looked at a gui tool to monitor and analyze a live application’s memory usage. This time, let’s turn to a command-line tools that can look at things after-the-fact: the heapy gem.

Ruby version 2.1 introduced the ability to take heap memory dumps using the ObjectSpace module. To do so, just add:

require 'objspace'

ObjectSpace.trace_object_allocations_start

…to your application boot. Later on, when you want to take a heap memory dump, you can use:

GC.start
ObjectSpace.dump_all(
  output: File.open('heap-dump.json', 'w')).close

You will find a heap-dump.json in your project folder (in production you could upload this file to S3 for later analysis). To analyze it with heapy, just do:

$ gem install heapy
$ heapy read heap-dump.json

By default heapy will show you a list of all GC generations:

Analyzing Heap
==============
Generation: nil object count: 11978
Generation:   6 object count: 74
Generation:   7 object count: 604
Generation:   8 object count: 1778
Generation:   9 object count: 1403
Generation:  10 object count: 3651
Generation:  11 object count: 3047
...

You can look at stats for a specific generation:

$ heapy read heap-dump.json 6

Analyzing Heap (Generation: 6)
-------------------------------

allocated by memory (3867) (in bytes)
==============================
  600  ~/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/specification.rb:2040
  456  ~/.rvm/gems/ruby-2.3.1/specifications/pry-0.10.4.gemspec:4
  320  ~/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/requirement.rb:107
...

object count (74)
==============================
  11  ~/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/specification.rb:2040
   8  ~/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/requirement.rb:107
   5  ~/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/specification.rb:1164
...

High Ref Counts
==============================

  33  ~/.rvm/gems/ruby-2.3.1/specifications/pry-0.10.4.gemspec:4
  12  ~/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/specification.rb:1525
   8  ~/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/requirement.rb:107
...

Duplicate strings
==============================

 4  "~>"
 4  ~/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/requirement.rb:107

 2  "method_source"
 1  ~/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/specification.rb:1164
 1  ~/.rvm/gems/ruby-2.3.1/specifications/pry-0.10.4.gemspec:29
...

Or you can ask for stats for all generations with:

$ heapy read heap-dump.json all

That’s it for heapy, short and sweet!

finding dead ruby code with debride

Sat, 29 Oct 2016 13:25:42 +0100

My recent web adventures led me to the debride gem: debride statically analyzes your ruby code, trying to find methods which are never referenced.

As ruby is a very dynamic language, you’ll get some amount of false positives, but I was successful in finding several unused methods on several of our years-old codebases at Talkdesk.

The output of running debride is a list of methods (and which class or module they belong to) that debride cannot find a reference to in the code.

My workflow to remove unused code is to run debride, and for each method:

grep the codebase to confirm that the method is not called or referenced in any way (e.g. invoked using :send or registered with a framework)
use the git pickaxe to discover when the method was introduced and its last user removed

During my quick experiment of about an hour I was able to delete about a hundred LoC—and I didn’t even get through the whole list!

debride is another interesting tool I’ve just added to my toolkit, and I hope it fits yours too.

psa: you can now debug with pry on jruby

Wed, 12 Oct 2016 22:05:41 +0100

I’ve been wanting to write this blog post for about a month now, but amongst the fixes for JRuby version 9.1.3.0 are a pair of fixes to backtrace line generation during debugging.

Why is this relevant? Because it means that you can now debug interactively from a pry console on JRuby too!

To do so, you can use either my fork of the pry-debugger gem, pry-debugger-jruby or the slightly simpler pry-nav gem.

You can include either of them in your Gemfile — I recommend pry-debugger-jruby as it has support for breakpoints:

# Gemfile
source 'https://rubygems.org'

gem 'pry-debugger-jruby'

Here’s a quick example which I’ll use to demonstrate its usage:

require 'pry'

def some_other_method
  puts "Hello,"
  puts "...stranger!"
end

def some_method
  binding.pry          # Execution will stop here.
  puts 'Hello, World!' # Run 'step' or 'next' in the
                       # console to move here.

  some_other_method
end

some_method

And here’s an example execution:

$ JRUBY_OPTS=--debug bundle exec ruby foo.rb

From: foo.rb @ line 9 Object#some_method:

     8: def some_method
 =>  9:   binding.pry          # Execution will stop here.
    10:   puts 'Hello, World!' # Run 'step' or 'next' in the
    11:                        # console to move here.
    12:
    13:   some_other_method
    14: end

[1] pry(main)> break foo.rb:5
Breakpoint 1: foo.rb @ line 5 (Enabled) :

    2:
    3: def some_other_method
    4:   puts "Hello,"
 => 5:   puts "...stranger!"
    6: end
    7:
    8: def some_method

[2] pry(main)> next
Hello, World!
Hello,

Breakpoint 1. First hit.

From: foo.rb @ line 5 Object#some_other_method:

    3: def some_other_method
    4:   puts "Hello,"
 => 5:   puts "...stranger!"
    6: end

[2] pry(main)> finish
...stranger!

Note that you have to either pass the --debug flag onto the jruby executable, or add it to the JRUBY_OPTS environment variable to enable debugging, otherwise you’ll just get an error when you try to use the debugging facilities.

Also note that I recommend you use --debug only when needed, as it slows down application (and spec) execution by quite a lot!

Hope this was helpful, and happy debugging!

peek and pick at mri's heap, part 1

Mon, 10 Oct 2016 22:20:28 +0100

While I’ve been spending a lot more time on JRuby-land, over the past year a number of very interesting tools have sprung up to analyze and debug MRI memory usage which are not very known but are rather kick-ass.

So without further ado, here is the first of three tools you can use to look at your MRI heap, rather than just banging your head against the table when you have to investigate memory problems: Rbkit.

Rbkit is composed of two components: the rbkit gem, which you include as usual in your Gemfile, and a desktop client application which connects to your ruby app and allows you to interact with it—and that you’ll have to download and install separately from Rbkit’s website.

To use it, just

require 'rbkit'
Rbkit.start_profiling

and start your application. Then just open up the rbkit desktop application and use the default connection settings to connect to your application.

Besides the real-time memory charts, Rbkit also allows you to monitor the multiple GC generations…

…take heap dumps…

…and compare heap dumps.

Unfortunately, I wasn’t able to get Rbkit to work with ruby 2.3.1, but it works without issues on 2.2.5, so even if you normally run 2.3.1, it’s probably not very hard to get your app on 2.2.5 while you’re debugging some issue.

You also cannot save heap dumps for later analysis (or with other tools), so hopefully that’s an improvement that will soon be contributed to the gem.

Overall, Rbkit is a very interesting tool to add to any rubyst’s toolbelt. Stay tuned for parts 2 and 3, where I’ll look at more awesome tools to peek and pick at mri’s heap!

why you should regenerate your spec_helper

Sun, 25 Sep 2016 14:32:23 +0100

If your project is like most ruby projects, your spec_helper.rb looks something like this:

# encoding: utf-8

if RUBY_ENGINE == 'rbx'
  require 'codeclimate-test-reporter'
  CodeClimate::TestReporter.start
end

require 'dry/container'
require 'dry/container/stub'

Dir[Pathname(__FILE__).dirname.join('support/**/*.rb').to_s].each do |file|
  require file
end

Pretty straightforward, and also missing on a lot of cool rspec features.

Modern rspec versions (as I’m writing this, the latest version is 3.5.4) have a lot of cool features that are not enabled by default, so as not to break backwards compatibility. What this means is that in practice, unless you turn them on, you’re missing out on a lot of goodies and cool features that could help you spot potential issues in your code and specs.

The quickest way to enable them is to ask rspec to generate a pair of new spec_helper.rb and .rspec files for your project.

generating a new `.rspec` and `.spec_helper`

Make sure you’re using the latest rspec:

$ bundle update rspec
# ... bundler output ...
Bundle updated!
$ rspec -v
3.5.4

Save your existing files (if any) by renaming them

$ mv .rspec old_dot_rspec
$ mv spec/spec_helper.rb spec/old_spec_helper.rb

…then ask rspec to generate you a new set of files.

$ rspec --init
  create   .rspec
  create   spec/spec_helper.rb

Let’s take a look at these files to see what they get you.

The newly-generated `.rspec`

--color
--require spec_helper

The .rspec file specifies default flags that get passed to the rspec command when you run your tests. So if you want one of the options you see listed on rspec --help to apply by default, you can add them here.

The two flags that are added by default are --color, that enables coloring in the rspec output, and --require spec_helper, that automatically requires the spec_helper file whenever you run rspec, rather than you have to manually add require 'spec_helper' at the top of your specs.

The latter option is more important than it seems. The spec_helper.rb we just generated (and that I’ll go into detail below) sets a number of options, but you only get them if, obviously, the spec_helper.rb is loaded by your specs. Forgetting the require may mean that when a spec is executed in isolation it may give a different result than when you execute your whole spec suite, which is troubling.

So rather than worrying about the next time you’ll forget to include the magic require, just let the .rspec always do it for you, and never worry about this again!

The newly-generated `spec/spec_helper.rb`

So we arrive at last to the meaty part. So what are these newfangled features that we get by regenerating the spec_helper, then?

The `include_chain_clauses_in_custom_matcher_descriptions` option

config.expect_with :rspec do |expectations|
  # This option will default to `true` in RSpec 4. It
  # makes the `description` and `failure_message` of
  # custom matchers include text for helper methods
  # defined using `chain`, e.g.:
  #   be_bigger_than(2).and_smaller_than(4).description
  #     # => "be bigger than 2 and smaller than 4"
  #   ...rather than:
  #     # => "be bigger than 2"
  expectations
    .include_chain_clauses_in_custom_matcher_descriptions =
      true
end

The include_chain_clauses_in_custom_matcher_descriptions option gets you improved descriptions and failure messages when you’re using multiple custom matchers, and you can find a handy example in rspec’s documentation.

Of course, this one only applies if you’re using your own matchers, so let’s move on to bigger fish.

The `verify_partial_doubles` option

config.mock_with :rspec do |mocks|
  # Prevents you from mocking or stubbing a method that does
  # not exist on a real object. This is generally
  # recommended, and will default to `true` in RSpec 4.
  mocks.verify_partial_doubles = true
end

This option is truly awesome. When you enable it, rspec also checks during the test suite execution that any mocks you setup are consistent with the original class being mocked.

What does this mean in practice? Well, consider that you’re mocking the :delete operation on the File class because you don’t want your test suite to be deleting real files during its execution, but you end up mistyping :delete as :delte.

allow(File).to receive(:delte)

If you then exercise your code, your specs may still pass, but instead of mocking the delete operation, you may be doing real deletes!

When you enable this option you’ll instead get as an output of your test run:

 Failure/Error: allow(File).to receive(:delte)
   File does not implement: delte
 # ./spec/foo_spec.rb:4:in `block (2 levels) in <top (required)>'

Another big benefit of this option is when mocking external libraries. Whenever you upgrade to a new major version a library, you may be led to believe that your code still works if you ran your specs and you’re still all green. But, however, if you’re mocking methods that no longer exist in the new library version, you can be in for a big surprise when you deploy your changes.

Using the verified doubles, your specs will fail right away if you’re using mocked objects wrongly. So upgrading major versions just got easier and your test suite leaves you more confident!

Note that these verified doubles check not only that a method exists, but also the number of arguments, and whenever keyword arguments are in use, if the proper required and optional keyword arguments are being used. So a whole lot of awesome 🎉!

The `shared_context_metadata_behavior` option

# This option will default to `:apply_to_host_groups`
# in RSpec 4 (and will have no way to turn it off --
# the option exists only for backwards compatibility
# in RSpec 3). It causes shared context metadata to
# be inherited by the metadata hash of host groups
# and examples, rather than triggering implicit
# auto-inclusion in groups with matching metadata.
config
  .shared_context_metadata_behavior = :apply_to_host_groups

This is also a very minor change to behavior of shared contexts, but the new behavior will be the default and only option in rspec 4, so enabling this today helps makes your specs forward-compatible with the next major rspec release.

For more details on this option see the rspec 3.5 release announcement and the api documentation.

Suggested settings in `spec/spec_helper.rb`

If you’re following along an automatically-generated spec_helper.rb as I suggested above, you’ll now get to a section of suggested options that are by default commented out.

# The settings below are suggested to provide a good
# initial experience with RSpec, but feel free to customize
# to your heart's content.

I believe most of them are rather useful, so let’s start turning them on!

The `filter_run_when_matching` option

# This allows you to limit a spec run to individual
# examples or groups you care about by tagging them with
# `:focus` metadata. When nothing is tagged with
# `:focus`, all examples get run. RSpec also provides
# aliases for `it`, `describe`, and `context` that include
# `:focus` metadata: `fit`, `fdescribe` and `fcontext`,
# respectively.
config.filter_run_when_matching :focus

The filter_run_when_matching option allows you to easily restrict your test suite execution to a specific subset of specs. This is helpful when you’re working on a number of classes and don’t want any other specs to run for now.

To trigger this behavior, just add the :focus option after describe, context or it to any specs or groups of specs you want to select:

RSpec.describe 'Foo', :focus do
  # ...
end

RSpec.describe 'Bar' do
  context 'when made out of iron', :focus do
    # ...
  end
end

RSpec.describe 'Baz' do
  it 'does stuff', :focus do
    # ...
  end
end

In the above example, all specs tagged with :focus will be executed, and any other specs in the test suite will be left out.

As a shorthand, you can also prepend an f to describe (fdescribe), context (fcontext), or it (fit) to get the same effect:

RSpec.fdescribe 'Foo' do
  # ...
end

RSpec.describe 'Bar' do
  fcontext 'when made out of iron' do
    # ...
  end
end

RSpec.describe 'Baz' do
  fit 'does stuff' do
    # ...
  end
end

Personally, I favor adding :focus as it’s harder to accidentally forget one in a commit ;)

The `example_status_persistence_file_path` option

# Allows RSpec to persist some state between runs in order
# to support the `--only-failures` and `--next-failure` CLI
# options. We recommend you configure your source control
# system to ignore this file.
config.example_status_persistence_file_path =
  'spec/examples.txt'

The example_status_persistence_file_path makes rspec remember which specs failed from your test suite.

This allows you to focus on fixing each failing spec one-by-one by running rspec --next-failure, or to just limit the test suite execution to the failing specs with rspec --only-failures.

As an example, consider the following execution:

$ rspec

Foo
  should not fail (FAILED - 1)
  when you really want to Foo
    really should not fail (FAILED - 2)

Bar
  works nicely

Failures:

  1) Foo should not fail
     Failure/Error: fail
     RuntimeError:
     # ./spec/foo_spec.rb:3:in `block (2 levels) in <top (required)>'

  2) Foo when you really want to Foo really should not fail
     Failure/Error: fail
     RuntimeError:
     # ./spec/foo_spec.rb:8:in `block (3 levels) in <top (required)>'

Finished in 0.00085 seconds (files took 0.07439 seconds to load)
3 examples, 2 failures

Failed examples:

rspec ./spec/foo_spec.rb:2 # Foo should not fail
rspec ./spec/foo_spec.rb:7 # Foo when you really want to Foo really should not fail

In this case, I ran the test suite, and it resulted in 2 failed specs.

Now, if I run again with rspec --only-failures, rspec will only retry the failed specs, in this case, those for Foo, and will not run the spec for Bar, which was working correctly.

$ rspec --only-failures
Run options: include {:last_run_status=>"failed"}

Foo
  should not fail (FAILED - 1)
  when you really want to Foo
    really should not fail (FAILED - 2)

Failures:

  1) Foo should not fail
     Failure/Error: fail
     RuntimeError:
     # ./spec/foo_spec.rb:3:in `block (2 levels) in <top (required)>'

  2) Foo when you really want to Foo really should not fail
     Failure/Error: fail
     RuntimeError:
     # ./spec/foo_spec.rb:8:in `block (3 levels) in <top (required)>'

Finished in 0.00074 seconds (files took 0.07481 seconds to load)
2 examples, 2 failures

Failed examples:

rspec ./spec/foo_spec.rb:2 # Foo should not fail
rspec ./spec/foo_spec.rb:7 # Foo when you really want to Foo really should not fail

Finally, if you really want to focus and tackle failing specs one-by-one, you can use rspec --next-failure and only the first of the failing specs will be executed.

$ rspec --next-failure
Run options: include {:last_run_status=>"failed"}

Foo
  should not fail (FAILED - 1)

Failures:

  1) Foo should not fail
     Failure/Error: fail
     RuntimeError:
     # ./spec/foo_spec.rb:3:in `block (2 levels) in <top (required)>'

Finished in 0.00055 seconds (files took 0.07577 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/foo_spec.rb:2 # Foo should not fail

This option is somewhat like :focus above, but rspec automatically focuses you on failing specs.

The `disable_monkey_patching!` option

# Limits the available syntax to the non-monkey patched
# syntax that is recommended. For more details, see:
#   - http://rspec.info/blog/2012/06/rspecs-new-expectation-syntax/
#   - http://www.teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/
#   - http://rspec.info/blog/2014/05/notable-changes-in-rspec-3/#zero-monkey-patching-mode
config.disable_monkey_patching!

Monkey-patching, e.g. the practice of extending or changing system or external library code during runtime, is both a blessing and a curse in Ruby.

Earlier versions of rspec employed a number of monkey patches to provide the DSL syntax used in tests. Unfortunately, this collided with ruby’s delegation mechanisms and thus a few releases ago the rspec developers came up with a new matching syntax (the expect-based one) that avoids the need for monkey patching.

For compatibility reasons, some of the monkey patches are still enabled by default, but their use is no longer recommended, and the disable_monkey_patching! option disables them for good.

In most projects I’ve found that the only monkey patches still in use are top-level describe and context blocks:

describe 'Foo' do
  context 'when fooing' do
    # ...
  end
end

context 'when the current planet is the earth' do
  describe 'clouds' do
    # ...
  end
end

Running these specs with disable_monkey_patching! will yield something like:

$ rspec
spec/foo_spec.rb:1:in `<top (required)>': undefined method `describe' for main:Object (NoMethodError)

To fix this, just prefix any top-level describe and context with the RSpec class:

RSpec.describe 'Foo' do
  context 'when fooing' do
    # ...
  end
end

RSpec.context 'when the current planet is the earth' do
  describe 'clouds' do
    # ...
  end
end

In most cases adding RSpec. to top-level blocks should be enough. Notice that contexts and describes nested inside the top-level blocks do not need to be modified.

If, however, some of your specs still make use of the old should matching syntax, consider using the transpec gem to automatically update your code to the newer expect syntax—no manual work needed!

The `warnings` option

# This setting enables warnings. It's recommended, but in
# some cases may be too noisy due to issues in dependencies.
config.warnings = true

This is one of the options I recommend the most. By default, even when running rspec, ruby does not emit warnings for valid, but possibly buggy code, such as:

Require loops (file foo.rb requires bar.rb, which requires foo.rb)
Unused variables
Using the value of an uninitialized variable
Redefining a method in the same scope as the original definition
Obsolete library usage
…

This option enables these warnings while running your test suite. You may find interesting things, not only on your suite, but on your own dependences—many of which also have warnings disabled on their own test suites and thus never noticed that these potential issues were there (see also below for a discussion on this).

Enable detailed rspec output when running only for a single file

# Many RSpec users commonly either run the entire suite or
# an individual file, and it's useful to allow more verbose
# output when running an individual spec file.
if config.files_to_run.one?
  # Use the documentation formatter for detailed output,
  # unless a formatter has already been configured
  # (e.g. via a command-line flag).
  config.default_formatter = 'doc'
end

For larger test suites, it’s usual to use the default rspec output where you print a dot for a passed spec, and an F for a failed one.

$ rspec
................

Finished in 0.00192 seconds (files took 0.07474 seconds to load)
16 examples, 0 failures

This tweak changes rspec’s behavior to output a detailed description of the tests when you run it with a single file (or only a single file is in :focus):

$ rspec spec/foo_spec.rb

Foo
  should not fail
  when you really want to Foo
    really should not fail

Finished in 0.0006 seconds (files took 0.07574 seconds to load)
2 examples, 0 failures

Simple, but useful :)

The `profile_examples` option

# Print the 10 slowest examples and example groups at the
# end of the spec run, to help surface which specs are
# running particularly slow.
config.profile_examples = 10

Remember the golden days of your project, when the entire test suite ran in under 10 seconds? The profile_examples option lists the slowest-running specs in your suite, which really highlights where time is being spent—perhaps the sleep you just added isn’t that innocent after all.

Personally, I find that 10 examples is a bit too noisy, and set it to either 3 or 5, but I find this option really useful to spot slow specs that are candidates for simplification, allowing your test suite to be blazingly-fast again.

$ rspec

Foo
  should not fail
  when you really want to Foo
    really should not fail

Bar
  works nicely

Top 3 slowest examples (0.00019 seconds, 20.5% of total time):
  Foo should not fail
    0.00009 seconds ./spec/foo_spec.rb:2
  Bar works nicely
    0.00005 seconds ./spec/foo_spec.rb:14
  Foo when you really want to Foo really should not fail
    0.00005 seconds ./spec/foo_spec.rb:7

Top 2 slowest example groups:
  Foo
    0.00023 seconds average (0.00045 seconds / 2 examples) ./spec/foo_spec.rb:1
  Bar
    0.00015 seconds average (0.00015 seconds / 1 example) ./spec/foo_spec.rb:13

Finished in 0.00092 seconds (files took 0.07551 seconds to load)
3 examples, 0 failures

Random spec ordering

# Run specs in random order to surface order dependencies.
# If you find an order dependency and want to debug it, you
# can fix the order by providing the seed, which is printed
# after each run.
#     --seed 1234
config.order = :random

# Seed global randomization in this process using the
# `--seed` CLI option.
# Setting this allows you to use `--seed` to
# deterministically reproduce test failures related to
# randomization by passing the same `--seed` value as the
# one that triggered the failure.
Kernel.srand config.seed

By default, rspec runs your specs in the order that they are defined (and your specs in alphabetic order). This helps during development—and I find myself temporarily enabling in-order execution when writing specs with rspec --order defined often—but may be hiding bugs.

How so? Consider a very simple example from my did_you_know.ruby? presentation:

class Bar
  def self.hello
    message =
      ENV['MESSAGE'] || 'hello'
    puts message
  end
end

RSpec.describe Bar do
  describe '#hello' do
    it 'prints hello' do
      expect(Bar).to receive(:puts).with('hello')
      Bar.hello
    end

    it 'is set prints the message in ENV['MESSAGE']' do
      ENV['MESSAGE'] = 'hello world'
      expect(Bar).to receive(:puts).with('hello world')
      Bar.hello
    end
  end
end

These specs pass when executed in order, but fail whenever the spec that sets the ENV['MESSAGE'] runs before the one that tests that it prints hello.

Now this example is pretty trivial, but in a big test suite it’s possible that quite accidentally one spec is leaving behind state that makes other tests either pass when they shouldn’t, or fail mysteriously.

Thus, the rspec order option enables random spec ordering, making rspec pick a randomized order for executing your specs, making sure that sooner or later code or specs that fail sporadically is found.

Whenever rspec runs with a randomized test ordering it prints a random seed—a value which you can use to repeat that exact ordering, when something files.

To run your specs with that seed, just run rspec --seed seed_value. And if you find yourself scratching your head finding which specs are interfering with each other, you can see an example of using rspec’s --bisect option on my presentation.

My test suite was green and now it fails! :(

Some of the options I suggest above may uncover issues in your code (in the case of verified partial doubles or random spec ordering) or on your test suite when you still used outdated rspec syntax (in the case of the disable monkey patching option).

If you find yourself in this situation, I recommend disabling the options again and enabling them one-by-one until you see the culprit. And when you do, I recommend looking into it, as you may have just uncovered a bug somewhere in your code.

Easiest open-source contribution ever!

As I’ve alluded to above, many existing gems also have outdated rspec configurations and cause lots of warnings when executed.

This means that contributing updated rspec configurations and fixes for warnings is one of the easiest ways you can start contributing to a project.

So that’s exactly what I’ve been doing:

So if you’ve been eyeing a project, here’s your chance! And if you just enabled warnings in your own code, and see that everyone else’s is causing warnings, help fix them! :)

Thanks for reading thus far!

explaining git

Sat, 03 Sep 2016 19:44:15 +0100

Recently I have a quick presentation on how git works during Talkdesk’s TGIF presentation slot.

I find that knowing some of these details really makes git “click” and easy to understand, as most (very awesome) git functionality can be simply mapped a bunch of operations on commit graphs and on plain text files that store commit hashes.

Here it is, in all its badly-illustrated glory:

Feel free to leave some kick-ass git tool suggestions in the comments. Or not :)

another round of jruby goodness

Sun, 17 Jul 2016 17:36:10 +0100

That was fast! Another?

Indeed. I have to confess that I spent the weekend reading through “Deploying with JRuby 9k” by Joe Kutner and following some of the links in the book, which led to a lot of cool discoveries.

If you’re looking at JRuby for more than a small test app, I do recommend it, although as it has a lot of examples and commands I fear may become outdated fast as tools evolve. So that’s why you should get it while it’s hot (no commission here, just a happy camper)!

So without further ado…

jruby-lint: see how ready your ruby code is for the J

The jruby-lint gem—also maintained by the JRuby developers—looks at your code and Gemfile and warns you of things that may pose issues when using JRuby:

./Gemfile:24: [gems, warning] Found gem 'oj' which is reported to have some issues:
Try gson, json or json_pure instead.
Try any one of the following JRuby-based servers: Trinidad, Mizuno, Kirk or Puma (though make sure to use the JRuby-native version of the gem).
./Gemfile:43: [gems, warning] Found gem 'bson_ext' which is reported to have some issues:
bson_ext isn't used with JRuby. Instead, some native Java extensions are bundled with the bson gem.
./Gemfile:59: [gems, warning] Found gem 'nokogiri' which is reported to have some issues:
For best results, use the pure-Java version of Nokogiri (default after v1.5).
./app/controllers/api/user_controller.rb:25: [nonatomic, warning] Non-local operator assignment is not guaranteed to be atomic

The developers are still hoping to further improve this gem, but it’s a good starting point for a project looking at going the JRuby way.

`bundler install --binstubs`, or having your cake and eating it too

In my previous post on JRuby I mentioned that running commands with bundle exec meant longer start-up times, as that meant booting up a JVM with JRuby for bundler, which would then fork another JVM with JRuby for the target command.

I suggested as a workaround to not run the commands inside bundler, but by doing that you’re giving up a lot of bundler’s goodness.

But little did I know that there was an alternative, even better solution: the --binstubs option! When running bundle install --binstubs, bundler creates small ruby wrappers for each command supplied by the installed gems (e.g. rspec, pry, puma, etc) in a bin/ folder inside your project directory.

Using these wrappers to run commands from gems, you get the same environment and setup you’d get from bundler, but avoid the slow behavior that you’d get from using bundle exec. So you get a correct environment—check ✔—and speed—check ✔.

You do have to remember to run, e.g. bin/rspec instead of bundle exec rspec. But for that I suggest having your shell do the work for you:

# Example code for .bashrc

functionBer() {
  if command -v bin/rspec; then
    bin/rspec $*
  else
    bundle exec rspec $*
  fi
}

alias ber=functionBer

This creates a ber alias for running rspec that will run the command using the binstub if possible, and fall back to bundler if there isn’t one (e.g. maybe you don’t want to have binstubs on all your ruby projects… yet).

jruby has its own built-in profiler

You can run JRuby with the --profile, --profile.graph or --profile.html options to get a performance report at the end of the application run.

$ JRUBY_OPTS="--profile --dev" pry -e "puts 'hello'; exit"
[1] pry(main)> puts 'hello'; exit
hello

main profile results:
Total time: 2.11

total   self children calls  method
---------------------------------------------
 1.48   0.02     1.46   894  Kernel.require
 1.23   0.01     1.22  4060  Array#each
 1.00   0.00     1.00     1  Gem::ExecutableHooks.run
 1.00   0.00     0.99   839  Proc#call
 0.95   0.07     0.88    26  Kernel.load
 0.93   0.00     0.93   159  Kernel.require
 0.78   0.00     0.78     1  Noexec#check
 0.78   0.00     0.78     1  Noexec#setup
 0.64   0.08     0.56   151  Kernel.eval
 0.48   0.08     0.40  4840  Class#new
 0.39   0.00     0.39     1  Noexec#candidate?
 0.31   0.01     0.31   158  Gem::Specification.load
...

You can also use --profile.api to get access to an api to selectively turn profiling on and off in certain parts of your code.

See the JRuby wiki for more details on these options.

getting some jruby magic in jconsole

By running JRuby with the --manage option, you’ll enable several JRuby jmx extensions, allowing you to do things such as executing ruby code on a running JRuby instance, or getting a full ruby stack trace for all running ruby threads.

You can then access them using jconsole, a tool already included with most JDK installs.

you can also use good ol’visualvm

The VisualVM tool is also installed by default on most JDK distributions (start it with visualvm or jvisualvm) and allows you to inspect a running VM, trigger garbage collection or heap dumps, and analyze cpu and memory consumption both via a profiler and a sampler.

Furthermore, if you include -J-Djruby.reify.classes=true as one of your JRUBY_OPTS then JRuby will generate a Java class for each ruby class, resulting on this very beautiful result from a sample application using sidekiq:

Just… amazing…

Update, 17th January 2017: Note that the reify.classes option is experimental so carefully test it before using it in a production environment.

that’s all very great, old chap, but i deploy using heroku

Hey, what a coincidence, I do too. The heroku exec plugin has you covered.

You read that right. You can connect tools such as visualvm to a running heroku dyno and monitor it. And take heap dumps. And execute ruby snippets. Securely.

**mindblown** **manly tears**

Obviously, with great power comes great responsibility, but every tool is welcome on my toolkit when debugging hard production issues.

Did you know you can deploy .war files (generated with warbler) directly to heroku?

And did you know you can deploy docker images to heroku? See the heroku-container-tools and documentation.

– I didn’t.

Until next time!

down the jruby rabbit hole

Sat, 16 Jul 2016 22:24:51 +0100

So recently at work we finally decided (after some prodding from me) to go with JRuby for a new production system.

I had no real experience with JRuby other than looking at some documentation and playing with it for five minutes, so here’s some JRuby-related topics I bumped into and I’ve been wanting to write about.

start-up time during development

Since the system hasn’t yet been deployed, I don’t have deployment stories to share, but for development I have some tips:

export JRUBY_OPTS='--dev'

Do define the magic --dev default option in your local development environment!

With this flag active, JRuby optimizes for startup time, so your fast rspec cycles and pry usage stops being painful.

(Of course, do note that steady-state performance will drop, so don’t use this for long-running code.)
Use binaries directly (or with jruby -S) rather than with bundle exec whenever possible. On my machine running rspec or jruby -S rspec instead of bundle exec rspec slices start-up time in about half.

These tips are documented in the JRuby wiki but I can’t stress enough the difference they make between JRuby being painful and a pleasure to use during development.

Edit: I suggest also looking at the --binstubs bundler option.

easy interop with java code

Don’t abuse it, but I must say it’s really easy to call Java code:

[1] pry(main)> require 'java'
=> false
[2] pry(main)> l = java.util.ArrayList.new()
=> #<Java::JavaUtil::ArrayList:0x7c24b813>
[3] pry(main)> l.add(:foo)
=> true
[4] pry(main)> l.add(:bar)
=> true
[5] pry(main)> l.to_string
=> "[foo, bar]"

bonus: warbler and the magical jar

While you can use bundler and many of the same techniques and platforms you are used to with mri (such as the puma webserver), an interesting tool I’ve recently discovered that is also developed by the JRuby team is warbler.

Warbler allows you to package a ruby application as a single jar or war file, that can be executed like any other java code standalone or (if applicable) on an application server. If needed, it can even bundle in a Java webserver that will call your ruby code.

Turning a simple ruby script into an inconspicuous jar is as simple as:

$ gem install warbler
Fetching: jruby-jars-9.1.2.0.gem (100%)
Successfully installed jruby-jars-9.1.2.0
Fetching: jruby-rack-1.1.20.gem (100%)
Successfully installed jruby-rack-1.1.20
Fetching: rubyzip-1.2.0.gem (100%)
Successfully installed rubyzip-1.2.0
Fetching: warbler-2.0.3.gem (100%)
Successfully installed warbler-2.0.3
Parsing documentation for jruby-jars-9.1.2.0
Installing ri documentation for jruby-jars-9.1.2.0
Parsing documentation for jruby-rack-1.1.20
Installing ri documentation for jruby-rack-1.1.20
Parsing documentation for rubyzip-1.2.0
Installing ri documentation for rubyzip-1.2.0
Parsing documentation for warbler-2.0.3
Installing ri documentation for warbler-2.0.3
Done installing documentation for jruby-jars, jruby-rack, rubyzip, warbler after 1 seconds
4 gems installed

$ cat bin/test.rb
puts "hello, world!"

$ cat config/warble.rb
Warbler::Config.new do |config|
  config.features = %w(executable)
  config.jar_name = "test"
end

$ warble jar
rm -f test.jar
Creating test.jar

$ java -jar test.jar
hello, world!

And that’s all there is to it, and you now have a single jar that anyone will be able to easily run on their local machine.

Big kudos to the JRuby team for this one!

dealing with java jar dependencies

So one of my colleagues asked: what about jars? Do you have to break out maven? How does that work?

The answer turns out to be no, you can just use jbundler to do that work for you. It looks and feels like bundler, and you feed it with a Jarfile and magic happens.

Of course, approach this with care, as when you start depending on Java code you cannot go back to MRI or other ruby implementations.

a shout out to jruby+truffle

I’m really looking forward to what I believe is the next big thing in the ruby implementation arena: JRuby+Truffle.

Its name can be somewhat misleading, as it’s a very different beast from vanilla JRuby. JRuby+Truffle instead uses a self-optimizing AST interpreter that basically teaches the JVM (via the truffle api and the graal compiler) how ruby works and how to optimize its execution.

The resulting benchmarks are looking very good, although a few sharp edges still stand before it can really be rolled out to production.

Chris Seaton, its creator, gave an awesome talk about it recently at VMSS16, which I really recommend watching:

P.s.: There are a lot of other great talks from that event, such as Cliff Click’s.

crystal, I am disappoint

A few months ago I was really getting interested in the Crystal programming language but after discovering that it doesn’t have multi-threading it became kind-of meh.

As a shared-memory concurrency junkie, it really seems weird to have a new language being created that doesn’t properly consider concurrency. Hopefully in the future this will be fixed, but until then, it seems like JRuby and Elixir are where the parallel party’s at!

did_you_know.ruby?

Sat, 14 May 2016 17:16:00 +0100

Yesterday I did a small presentation on some awesome ruby tricks and tools, touching a bit on

why and when to use keyword arguments
splat and double splat
rspec’s verified doubles
rspec --bisect and random spec ordering
pry
ruby 2.3 dig and safe navigation
ruby threading and implementations

as part of talkdesk’s TGIF engineering presentations.

Nothing groundbreaking, but still interesting, I’d say ;)

You can find the slides below:

asciinema: shell recording done right!

Tue, 01 Dec 2015 22:19:07 +0000

Whoa! Java has a REPL now!

Sat, 28 Nov 2015 22:32:59 +0000

As part of my weekend reading I just discovered that an official REPL is planned for Java 9!

It’s spec’d in JEP 222, and there’s a very neat demo by Alex Zhitnitsky:

Even better, there’s even a docker image for testing it. Just run

$ docker run -it ensignprojects/javarepl

And before long you’ll be staring at the new jshell REPL!

Ruby meets weak memory models

Sat, 28 Nov 2015 20:14:23 +0000

I just finished watching a very interesting presentation from RubyConf 2015 entitled “Writing concurrent libraries for all Ruby runtimes” by Petr Chalupa.

This presentation explores the challenges of implementing a Future in ruby VMs that offer true concurrency, such as JRuby and Rubinius, and how the concurrent-ruby gem can make your life easier in this point.

If you’re interested in low-level concurrency and what happens to ruby code when run under these alternative VMs, it’s a great watch, even if the speaker can be slightly monotone at times ;) ;) ;)

Ruby features i'm looking forward to

Fri, 13 Nov 2015 00:03:33 +0000

I’ve been exploring what’s next for ruby, and now that ruby 2.3.0-preview1 is out, here’s a quick look at what caught my eye.

$ ruby --version
ruby 2.3.0dev (2015-11-11 trunk 52540) [x86_64-linux]

The safe navigation operator was inspired by groovy, and allows you to simplify code such as

zoo = Zoo.new
zoo && zoo.animals && zoo.animals.first

into

zoo&.animals&.first

If any of the return values in the “chain” are nil, then nil is returned, otherwise, ruby continues sending the next message.

Simple, and to the point. I like it!

Note that the safe navigation it does not interact with [] syntax sugar, for instance when indexing an hash:

values&.[:foo] # error
SyntaxError: unexpected '[', expecting '('
values&.[:foo]
         ^

You’ll have to unsugar the method call:

values&.[](:foo) # works

frozen string literals

In ruby 3.0, the plan is for strings to be immutable by default. The first step towards that path is a command-line option that optionally enables that behavior for ruby 2.3:

hello = "hello world"
hello['world'] = 'ruby'
puts hello

Running the example:

$ ruby immutable.rb
hello ruby

$ ruby --enable=frozen-string-literal immutable.rb
immutable.rb:2:in `[]=': can't modify frozen String (RuntimeError)
        from immutable.rb:2:in `<main>

Immutable strings have a number of concurrency and efficiency advantages, and are the standard in many other programming languages (such as Java), so it’s nice to see them make an appearance in ruby.

did_you_mean enabled by default

The did_you_mean gem is now bundled and should be enabled by default. It did not load for me, but after a manual installation I was greeted with success:

class Zoo
  def animals
    [:penguin, :lion]
  end
end

Zoo.new.animalZ

Running the example:

$ ruby zoo.rb
zoo.rb:7:in `<main>': undefined method `animalZ' for #<Zoo:0x00000000c97a70> (NoMethodError)

    Did you mean? animals

It’s a very minor addition, but it’s one of those small niceties that can draw a smile during your daily ruby adventures.

hash comparison

In previous ruby versions, you could check if two hashes were the same:

{lions: 'enough', penguins: 'lots'} ==
  {lions: 'enough', penguins: 'lots'}
=> true

But what if you wanted to check if a hash contained another? Well, previously you’d have to convert them into sets:

Set.new({lions: 'enough', penguins: 'lots'}) >
  Set.new({lions: 'enough'})
=> true

In ruby 2.3 you’ll be able to compare sets directly:

{lions: 'enough', penguins: 'lots'} > {lions: 'enough'}
=> true

Marvelous!

Thanks to Oliver Lacan for his awesome writeup of the feature.

looking ahead: goodbye to the GIL

MRI, the default ruby implementation, employs a lock called the global interpreter lock – GIL to her friends. This lock protects each executing ruby thread so that at any given moment only one thread is allowed to be executing ruby code.

This lock allows a number of simplifications and optimizations in the way the ruby internals are implemented, but is increasingly outdated given how even phones will soon have 10-core cpus.

The lack of real multi-threading has made ruby greatly lag behind other languages, and I’m really interested in seeing the ruby ecosystem successfully transition to a GIL-less model.

My vague plan for Ruby GIL is 1) add more abstract concurrency e.g. actors 2) add warning when using threads directly 3) then remove GIL
— Yukihiro Matsumoto (@yukihiro_matz) August 1, 2014

To tackle this, Matz and the ruby team have been working for some time to remove the GIL, and, beyond that, to offer powerful and easy-to-use tools for multi-threaded programming.

One such proposal is the stream operator, |>, that allows multiple components to be joined in a pipeline. It’s still under heavy work, but if you’re interested, you can check out the current implementation and Matz’s recent presentation on ruby 3.0.

on the next episode!

I recently discovered the crystal programming language, a ruby-inspired language that tries to keep ruby’s awesomeness, but make it compilable down to very efficient machine code.

I’ve been itching to take it for a spin, so maybe next time!

starting a new blog

Tue, 03 Nov 2015 21:58:49 +0000

I haven’t really blogged in a big while, and my old blog at blogspot seems to be more and more boring to maintain, so I finally decided to put jekyll to work and added a blog to ivoanjo.me.

I’m currently exploring Ruby and other programming languages, so my plan is to document some of my cooler findings for the larger internets.

Thank you and have an awesome day!

ivo's awfully random tech blog

Low-level Ruby observability APIs

Talking Ruby GVL, Scheduling and Performance on the Dead Code podcast

native-filenames: Find out where native methods are defined in Ruby

I wrote another weird ruby gem: direct-bind

M:N scheduling and how the (Ruby) global vm lock impacts app performance

Building an always-on (Ruby) production profiler

Backtracie and the quest for prettier Ruby backtraces

Look out! Gotchas of using threads in Ruby

Understanding the Ruby Global VM Lock by observing it

Ruby's unexpected I/O vs CPU unfairness

Talking Ruby Performance Tooling at the Ruby Rogues podcast

Ruby reuses native OS threads after Ruby Threads die

Hunting production memory leaks at RubyKaigi 2022

Tracing Ruby's (Global) VM Lock

what is the global vm lock?

actually, the global vm lock is no more!

let’s talk gvl tracing

using gvl-tracing: you need ruby 3.2+

using gvl-tracing: how to try it on your own applications

share your traces and learnings!

Talking Ruby Ractors and Concurrency at the Ruby Rogues podcast

The unexpected cost of Ruby's NoMethodError exception

Sunday Lol: Embedding images in commit logs

Ruby Ractor Experiments: Safe async communication

Looking into Array memory usage in Ruby

What’s in a Ruby object?

Let’s talk Arrays

The embedded shape

The extended shape

Growing an Array

Shrinking an Array

What I've been reading: December+January 2021 Edition

1. Painting a Selfie Girl, with Maths (YouTube Video):

2. LiFi (Product):

3. Nonlinear increases in complexity make unification excruciating (Blog Post):

4. On the Metal: Kenneth Finnegan (Podcast Episode):

5. Java Flight Recorder will support event throttling (Erm…​ JIRA ticket):

6. Napkin Math (Blog Posts):

7. No cookie for you (Blog Post):

8. Ditherpunk — The article I wish I had about monochrome image dithering (Blog Post):

9. Towards Continuous Performance Regression Testing (Blog Post):

10. Performance Summit London Edition II (Online Event):

11. Programming-Idioms Cheatsheets (Website):

What I've been reading: November 2020 Edition

1. Magic: the Gathering: Twenty Years, Twenty Lessons Learned (Conference Talk):

2. Up Sh*t Creek: Pro Tips for Managing the Unmanageable Project (Conference Talk):

3. 50 Game Camera Mistakes (Conference Talk):

4. Game Balance Concepts (Blog Posts):

5. BPF binaries: BTF, CO-RE, and the future of BPF perf tools (Blog Post):

6. Getting noticed as a remote engineer – and why it matters (Blog Post):

7. Breakpoint Day 1.4: Technology constraints drive automation (Talk):

8. One Size Fits None - (Everything You Learned in Your DBMS Class is Wrong) (Talk):

9. THE TYRANNY of STRUCTURELESSNESS (Essay):

10. The Impact of Toxic Influencers on Communities (Blog Post):

11. UX request: Tell, don’t hide (Blog Post):

12. ARM and Lock-Free Programming (Blog Post):

Creating a newsletter!

What I've been reading: October 2020 Edition

Better backtraces in Ruby using TracePoint

Snippet: Getting a dynamically-generated method name on the Java stack using Javassist

Ruby Experiment: Include class names in backtraces

Quick tip: Unsafe concurrent Ruby hash access

Kotlin Hack: Transparently replace class with interface

Mocking frameworks?

Solution part 1: Introducing an interface

Solution part 2: Faking the original class' constructor

Kotlin for Rubyists

Spotting unsafe Ruby patterns - Talk recording

Writing to a Java TreeMap concurrently can lead to an infinite loop during reads

TIL: Java hides lambda frames in stack traces

My thoughts on, and how I approach code reviews

Part I: Before submitting a review

1. Commits tell a story

2. Review your own code

3. Have a computer review your code

4. Be mindful of the diff and diff noise

5. Be mindful of the reviewer’s time/effort

6. Can you feature flag it?

7. Be comfortable enough to press the merge button immediately

5. Java Flight Recorder will support event throttling (Erm… JIRA ticket):

2. Up Sht Creek: Pro Tips for Managing the Unmanageable Project* (Conference Talk):

Is this ok…? Or, spotting unsafe concurrent Ruby patterns