The weak mapping from context Object instances to ContextCapabilities. Used to avoid recreating a ContextCapabilities every time a context is made current.

Maps threads to their current context's ContextCapabilities, if any

The getCapabilities() method is a potential hot spot in any LWJGL application, since it is needed for context capability discovery (e.g. is OpenGL 2.0 supported?), and for the function pointers of gl functions. However, the 'current_capabilities' ThreadLocal is (relatively) expensive to look up, and since most OpenGL applications use are single threaded rendering, the following two is an optimization for this case.

ThreadLocals can be thought of as a mapping between threads and values, so the idea is to use a lock-less cache of mappings between threads and the current ContextCapabilities. The cache could be any size, but in our case, we want a single sized cache for optimal performance in the single threaded case.

'fast_path_cache' is the most recent ContextCapabilities (potentially null) and its owner. By recent I mean the last thread setting the value in setCapabilities(). When getCapabilities() is called, a check to see if the current is the owner of the ContextCapabilities instance in fast_path_cache. If so, the instance is returned, if not, some thread has since taken ownership of the cache entry and the slower current_capabilities ThreadLocal is queried instead.

No locks are needed in get/setCapabilities, because even though fast_path_cache can be accessed from multiple threads at once, we are guaranteed by the JVM spec that its value is always valid. Furthermore, if the ownership test in getCapabilities() succeeds, the cache entry can only contain the correct ContextCapabilites (that is, the one from getThreadLocalCapabilites()), since no other thread can set the owner to anyone else than itself.

Reference count of the native opengl implementation library

Simple lock-free cache of CapabilitesEntryCache to avoid allocating more than one cache entry per thread