Relighting causing extreme memory/CPU usage

[Xorgon]

Server Implementation

Spigot

Server Version

1.21.10

Describe the bug

Upon copy/pasting a lighting block (and perhaps also a lighting-affected block such as a block inside a lighting glitch?), the relighter draws huge memory usage, eventually leading to high CPU usage as garbage-collection struggles to keep up, and eventually a non-functioning server.

Relogging will in some instances cancel the relighting job, effectively fixing the bug, but also leaves large areas of broken lighting that can lead to further instances of the bug (it would seem). In at least one case, subsequently logging on and trying to use WorldEdit commands resulted in a job cancellation due to low memory, despite memory being available.

To Reproduce

1. Start with blank server, just FAWE.
2. Log in, place a glowstone block.
3. //copy the glowstone block.
4. Move to a new position, use //paste.
5. Kaboom.

Expected behaviour

I expected the server to remain healthy ;)

Screenshots / Videos

https://xorg.us/idea64_2025-11-17_01-34-54.mp4

Error log (if applicable)

No response

Fawe Debugpaste

https://athion.net/ISPaster/paste/view/255ba270af8c4a90a7515c9527c2bda7

Fawe Version

FastAsyncWorldEdit version 2.14.1-SNAPSHOT-1214+6205e5c

Checklist

• I have included a Fawe debugpaste.
• I am using the newest build from https://ci.athion.net/job/FastAsyncWorldEdit/ and the issue still persists.

Anything else?

No response

[SirYwell]

Try with Paper instead of Spigot.

[Xorgon]

The bug does not reproduce on Paper. I'm guessing that's because it's using a different relighter.

From the Paper log:
[11:54:12] [AsyncNotifyKeyedQueue - 0/INFO]: Using com.sk89q.worldedit.bukkit.adapter.impl.fawe.v1_21_9.PaperweightStarlightRelighterFactory as relighter factory.

Whereas in the Spigot log (above):
[01:35:46] [AsyncNotifyKeyedQueue - 0/INFO]: Using com.fastasyncworldedit.bukkit.adapter.NMSRelighterFactory as relighter factory.

So presumably a bug in NMSRelighterFactory?

[Xorgon]

After some digging into what's going on inside NMSRelighter, it seems that the Map of visited blocks keeps growing endlessly. I set up a server with a bunch of RAM to see how far it would go. In the limit of my patience for that run, it got up to an area of ~800x800 blocks (horizontally). I've not had the time to figure out exactly why it's expanding endlessly, or how the lighting update system works, but I'm guessing that's not how it's supposed to go.

This is where that Map is initialised

FastAsyncWorldEdit/worldedit-core/src/main/java/com/fastasyncworldedit/core/extent/processor/lighting/NMSRelighter.java

Line 216 in 10a6743

Map<BlockVector3, Object> visited = new HashMap<>(32);

And it is added to here:

FastAsyncWorldEdit/worldedit-core/src/main/java/com/fastasyncworldedit/core/extent/processor/lighting/NMSRelighter.java

Line 803 in 10a6743

visited.computeIfAbsent(

And here:

FastAsyncWorldEdit/worldedit-core/src/main/java/com/fastasyncworldedit/core/extent/processor/lighting/NMSRelighter.java

Line 839 in 10a6743

visited.computeIfAbsent(