The G1 barrier queue locks are a mess.

1) Memory accesses are performed all over hotspot, so any locks required by GC barriers need to be out of the way, so that the G1 barriers adapt to the code base, rather than the code base adapting to G1 barrriers. As time went on and we saw just how many places that previously lacked G1 barriers, and added them in one-by-one, the problem has gotten worse.

2) Because of lock ordering problems (not inherent, but rather imposed by picking the wrong ranks), the PtrQueue::locking_enqueue_completed_buffer member function actually unlocks an outer lock to acquire an inner lock, and then re-acquires it, purely to avoid an assertion complaining about lock orders. This should simply be reflected by their ranks instead.

3) Because of problem #2, races have been introduced (unnecessarily) where there are multiple enqueuers of the same buffer. There is code and long comments in PtrQueue::handle_zero_index describing how these (completely unnecessary) races are handled. They should not happen in the first place, had the lock orderings been right.

I propose this type of locks warrant a new lock type called "access" for memory accesses - they have a lower rank than "special", because they are inherently more special than any of the locks that are "special" today. They can be called by JNIHandles::resolve if it happens to catch a jweak, and they can happen anywhere we have object stores intentional or not.