I also had a look at the the active contexts using the OpenGL Profiler on OSX. A strange thing I noticed is in the Context Id comboboxes, the destroyed contexts stay green until glfwTerminate is called. Also, when attaching the profiler after contexts were created and destroyed, they are still shown. It is difficult to find information about the way this list is created, or the meaning of the colors, so it is hard to say if this really means something...

OK, this was helpful and I've got a fix for you: Call glfwMakeContextCurrent(NULL) in the executor threads, after all other OpenGL calls (I did it in the clearBuffer action). Looks like NSOpenGLContext is not released as long as it's current in a thread. edit: that was not it, see below.

Sounds great! But I can't seem to make it work. Pushed my latest code to GitHub.
I added the following on the executor threads before destroying the window.
glfwMakeContextCurrent(MemoryUtil.NULL);Memory usage looks the same.

Sorry about that, the above suggestion indeed does not fix the problem. After a ton of testing, I've figured out what's happening and the fix is equally simple: Call glfwPollEvents() after window destruction.

The whole problem was a side-effect of never calling glfwPollEvents(). The OS X implementation of this method drains an internal NSAutoreleasePool, which deallocates any reference-counted objects that are no longer active. This includes any destroyed windows/contexts. If you never call glfwPollEvents(), all allocated objects will be stuck in the pool and never released.

Most GLFW programs run an event loop and it's not a bad decision to do memory cleanup once per frame. On the other hand, the documentation of glfwPollEvents() does not mention any memory management side-effects, so never calling it when all you're doing is creating contexts for offscreen rendering/computation feels like a legitimate thing to do. I'll open a GLFW issue for this.

Thanks, you're a hero!

The next problem is calling this method throws an error when it isn't called on the first/main thread (-XstartOnFirstThread), so when using offscreen rendering for JavaFX it won't work. Any way around this?

Nope, without glfwPollEvents(), you'll have to wait for a GLFW fix.

edit: see GLFW issue #721

This has been fixed in the latest nightly build (3.0.0 #51).