Ryoamic Lights

Ryoamic Lights

Minecraft 1.20.1 / Forge: this page documents that build and its measurements. For the separate 170-control Minecraft 1.21.1 port, see Minecraft 1.21.1 NeoForge.

Two controls for Ryoamic Lights 0.2.3+mc1.20.1 (mod id ryoamiclights), both client-side: the chunk rebuild loops run without boxing, and block-entity light checks skip the lock while no block entity is a light source. Every switch checks the code it would change against the tested build; another build is left untouched with one WARN line (see How the patches are applied).

Key	Target	Side	Since	Kind
ryoamiclights_block_entity_lock_skip	Ryoamic Lights 0.2.3+mc1.20.1	CLIENT	1.0.21	opt
ryoamiclights_chunk_iteration	Ryoamic Lights 0.2.3+mc1.20.1	CLIENT	1.0.3	opt

---

ryoamiclights_chunk_iteration

Since: 1.0.3 · Side: CLIENT · Scripts (1.0.19 and earlier): furious3-BlockEntityMixin.js, furious3-EntityMixin.js Patched: org.thinkingstudio.ryoamiclights.mixin.lightsource.BlockEntityMixin and EntityMixin (scheduleTrackedChunksRebuild) Mixins (since 1.0.20): EntityChunkRebuildMixin, BlockEntityChunkRebuildMixin

What upstream did. Ryoamic Lights (dynamic lighting) tracks the chunks a light source touched in a LongOpenHashSet and, on every rebuild, iterated it through the boxing iterator, allocating a Long for every chunk position.

What the patch does. Calls LongIterator.nextLong() instead. The world lookup, source membership check, locks, brightness calculation, update interval and rebuild order are unchanged.

What stays the same. Every rebuild request in the original order, including tracked-set mutations and world guards.

Measured. Block-entity loop 40.3 → 30.5 ns (−24.3 %); the entity loop was neutral. A warmed JIT already removes the boxing in some runs (48 → 0 B in one repeat); the interpreter-only loop measured 232 → 40 B for eight chunks. Kept because it is exact and never slower.

---

ryoamiclights_block_entity_lock_skip

Since: 1.0.21 · Side: CLIENT · Mixin: BlockEntityLockSkipMixin · Helper: bons.furious.patch.ryoamiclights.IdentityEquality Patched: org.thinkingstudio.ryoamiclights.RyoamicLights.addLightSource and containsLightSource

What upstream did. With block-entity light sources enabled, every ticking block entity asks containsLightSource twice per client tick, and each call takes and releases the global read lock to look in the light-source set.

What the patch does. addLightSource, the only way into that set, sets a sticky flag before its write lock whenever a block entity is about to be added. While the flag is clear, containsLightSource answers false for a block entity whose class keeps Object's equals and hashCode (checked once per class through MethodHandles) without taking the lock. The world check still runs first; entities, block entities with their own equality, and everything after the first block-entity light source keep the original locked lookup. Both method bodies are otherwise Ryoamic Lights' own (MIT).

What stays the same. Every answer: 2,000 randomized add/remove traces, including a block-entity class with an unusual equals, agreed with the original, and in the 1.0.21 client run all 376 loaded block entities gave the same answer as a locked lookup of the set.

Measured. 6.3 → 3.0 ns per uncontended check, two per block-entity tick. In two client profiles the check was 0.31 % / 0.25 % of the render thread, almost all of it from block-entity ticks.