Observation: The method reserveCustomAttrType has been changed to a synchronised method. This is a good practice for thread safety, but it introduces a potential bottleneck under heavy load.

Recommendation: Assess if finer-grained synchronisation (e.g., using atomic variables) could replace the synchronisation here to improve concurrency without sacrificing thread safety.

AI? Infrequently called, and relieves bottlenecks elsewhere. (Point of PR.)

Magic numbers are being used in conditional checks.
Recommended : Define these values as constants to improve code readability and maintainability:

May be valid, but not in scope of change.

It will be important that the list node is fully initialised and stable before it can be referenced by the unsynchronised reader in code like this:

I see that the lines of code here are sequenced so that the publication of the reference to the new node comes last. Now we have to be sure the compiler won't rearrange assignment before construction. ISTR either the JLS or Pugh explicitly mentions this possibility. We have guarantees about writes to an individual variable, but what about actions nearby in the programme order of the thread? I think the generous application of the volatile keyword may have achieved that, but as I've said, I find this stuff difficult to reason about securely.

As I understand the volatile semantics, having ob.attributes and (Transient)AttributeLink.next volatile should indeed prevent reordering of newAtt.setNext(att); and ob.attributes = newAtt;. Do you have an idea how we can confirm that? Perhaps by disassembling the bytecode of JyAttribute.class. That would be tedious and I suspect the JIT may apply subsequent optimization, including reordering where permitted. Perhaps an isolated test of JyAttribute concurrent access? Like 100 Threads read and write attributes permanently for 5 minutes for a dummy PyObject. This really stresses the design and the test would observe the results to confirm the anticipated behavior. Still tedious to implement. Read access would have to confirm that concurrent write access would never make an unrelated attribute (with higher index than the written one) temporarily invisible. Provoking an exception of any kind would of course be a fast-fail for the whole test.

I'm skeptical about changing the implementation more broadly (to create an entirely new list every time). If the volatile semantics does not work as expected and promised, that approach would be similarly broken. Proper initialization of the whole new list might be reordered with assignment to ob.attribute. A read access in the wrong moment could pick the uninitialized thing. So either it works as specified and it would be fine in any case, or it would be broken in any case. The new-list-every-time-approach would btw also require next to be volatile to prevent reordering of list initialization. Then, if we would make a new thing every time we could also make it an array. But also then, the array would have to be volatile to ensure proper initialization. However I'm not even aware what volatile would theoretically mean for an array (every item be like a volatile field I suppose).

All in all, the question of trust in the specs applies to each approach and we would likely need a proper stress test in any case. So I would go with the already implemented solution, wich is of all alternatives the one with the fewest changes to the status quo. Also, I do not see enough benefit to justify rewriting it yet again.

Good point about the array. And given that initialisation might skip round the write to ob.attributes I'm not convinced it helps. The idea was to reduce the number of volatile fields so we had only one to reason about instead of 3n+1 things.

That's the sort of test I meant, but it might not have to run so long if you could guarantee the threads compete. Inspecting the output of a particular compiler is not good enough. Our correctness has to be based on good theory and a reasonably harsh practical exam.