Skip to content

Conversation

@dordsor21
Copy link
Member

@dordsor21 dordsor21 commented Jul 26, 2024

@github-actions github-actions bot added the Bugfix This PR fixes a bug label Jul 26, 2024
@dordsor21 dordsor21 force-pushed the fix/chunk-get-write-improvements branch from 3b7e56e to 79a5a50 Compare July 28, 2024 18:25
@dordsor21 dordsor21 marked this pull request as ready for review July 30, 2024 14:30
@dordsor21 dordsor21 requested a review from a team as a code owner July 30, 2024 14:30
@NotMyFault NotMyFault requested a review from a team July 30, 2024 16:13
@dordsor21
Copy link
Member Author

fwiw I threw this at someone who experienced fewer issues after installing

@github-actions
Copy link

Please take a moment and address the merge conflicts of your pull request. Thanks!

 - ensure levelChunk is loaded before giving to copy GET - this is not necessarily guaranteed to be nonnull if two edits overlap. Whilst not advised, such an easy failure should not occur when two edits collide
…a chunk and vice versa

- alter IntPair hashcode to be more often unique
- Utilise ConcurrentHashMap for free synchronisation
}
return ReflectionUtils.compareAndSet(sections, expected, value, layer);
} finally {
chunks = SENDING_CHUNKS.get(worldName);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there any scenario where this is actually needed? The old reference should still be the correct one as we never remove it. Alternatively, did you consider using a ConcurrentHashMap<*WorldIntPair*, ChunkLock> instead? This way we won't have unused CHM instances laying around (which could probably be a problem with many temporary worlds).

Copy link
Member Author

@dordsor21 dordsor21 Sep 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was to reduce lock contention between worlds when locking/unlocking. I suppose the operations themselves shouldn't take too long, though perhaps it's worth having the CHM in a BukkitWorld instance so it's GCed as needed if still attempting to do this

I also think I was planning to remove from the map when a world is unloaded

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving it into BukkitWorld sounds good.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FAWE does not actually cache/limit the number of BukkitWorld instances, and given upstream does not either, it feels quite wrong to do this. I don't know if it's worth wrapping a WeakHashMap into a synchronised map and using the NMS world (or a normal bukkit world) as a key?

@dordsor21 dordsor21 requested a review from SirYwell September 21, 2024 12:38
@dordsor21 dordsor21 force-pushed the fix/chunk-get-write-improvements branch from a86c8d6 to cd6a701 Compare September 21, 2024 12:40
@dordsor21 dordsor21 merged commit b4635e8 into main Sep 25, 2024
@dordsor21 dordsor21 deleted the fix/chunk-get-write-improvements branch September 25, 2024 17:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bugfix This PR fixes a bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants