On Tue, 8 Apr 2025 18:39:30 GMT, kabutz <d...@openjdk.org> wrote: > In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are > dynamically created upon each insertion unless this would bring the deque > above capacity." However, in the current implementation, nodes are always > created, even if the deque is full. This is because count is non-volatile, > and we only check inside the linkFirst/Last() methods whether the queue is > full. At this point we have already locked and have created the Node. > Instead, the count could be volatile, and we could check before locking. > > In the current version, calling offer() on a full LinkedBlockingDeque creates > unnecessary objects and contention. Similarly for poll() and peek(), we could > exit prior to locking by checking the count field. > > Our suggestion is to make count volatile, and then exiting early from poll() > and offer()
If we strictly adhere to this interpretation of "create nodes", then we must only call a constructor after the locked capacity check has passed in places like `offerLast`, and this patch has not accomplished that yet. I think the correct way to interpret the spec here is that "create node" means a node is created in the linked list, so we can interpret that as a change in collection membership reflected in accessor methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24521#issuecomment-2803675483
