mirror of
https://github.com/PaperMC/Paper.git
synced 2025-01-09 19:49:35 +01:00
71ac6d7e6a
HashMapPalette uses an instance of CrudeIncrementalIntIdentityHashBiMap internally. A Palette has a preset maximum size = 1 << bits. CrudeIncrementalIntIdentityHashBiMap has an initial size but is automatically resized. The CrudeIncrementalIntIdentityHashBiMap is created with the maximum size in the constructor of HashMapPalette, with the aim that it doesn't need to be resized anymore. However, there are two things that I think Mojang hasn't considered here: 1) The CrudeIncrementalIntIdentityHashBiMap is resized, when its initial size is reached and not the next time, when a further object is added. 2) HashMapPalette adds objects (unnecessarily) before checking if the initial size of CrudeIncrementalIntIdentityHashBiMap is reached. This means to actually avoid resize operations in CrudeIncrementalIntIdentityHashBiMap, one has to add 2 to the initial size or add 1 and check the size before adding objects. This commit implements the second approach. Note that this isn't only an optimization but also makes async reads of Palettes fail-safe. An async read while the CrudeIncrementalIntIdentityHashBiMap is resized is fatal and can even lead to corrupted data. This is also something that Anti-Xray is currently relying on. |
||
|---|---|---|
| .. | ||
| status | ||
| storage | ||
| ChunkAccess.java.patch | ||
| ChunkGenerator.java.patch | ||
| ChunkGeneratorStructureState.java.patch | ||
| DataLayer.java.patch | ||
| EmptyLevelChunk.java.patch | ||
| HashMapPalette.java.patch | ||
| LevelChunk.java.patch | ||
| LevelChunkSection.java.patch | ||
| PalettedContainer.java.patch | ||
| ProtoChunk.java.patch | ||