Allocation fixes

[hydrozoa-yt]

Proposed changes

Currently, the program allocates a ton of new objects all the time, causing the gc to have to work overtime, and tanking the memory. When I run 10 min sessions of 2k bots running around, there's ~2 terabytes of memory allocations.

Most of it is byte[], Object[], Integer and Position.

Flame graphs tell me the Integer and Object[] is 100% due to hashCode of Position and Chunk. Ofcourse a server will have byte[] and Position allocations, so those are not as easy targets for lessening allocations.

This PR changes the hashCode functions and does away with a few Position allocations, greatly improving the 10 min run in terms of memory.

I also introduced alternative versions of Position.translate() that doesn't allocate.

Pull Request type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Further comments

Getting down to as few allocations as possible will be an ongoing process, and will have to be considered when adding new features.

[hydrozoa-yt]

Looking a lot better now, pic attached shows comparable 10 min run. The byte[] allocations are gone, deleting 1 TB worth of allocations.

[lare96]

The core code was designed with Position being immutable in mind so this could introduce a lot of breaking changes.

Better solution is to make a new MutablePosition class that can be easily transmuted to/from a regular position when needed. I think the biggest performance improvements will come from the hashing changes you've implemented as well as bit packing position and chunk classes so there's less garbage in general.

[hydrozoa-yt]

I have removed mutability from Position again. However, there are few places where new Position objects are allocated wastefully, mostly translations inside loops.

To mitigate the wastefulness we can either

1. Use records for Positions, as those optimize memory a bit compared to a regular class with only final fields.

2. Use value classes for Positions, allowing Positions to be treated as primitives, removing the object overhead of allocations. This is currently available in java 25 and 26 as a preview feature. This is probably the best solution as it's "free" in the sense that the code changes are minimal.