Describe the bug
In heavily modded minecraft, memory fills to its limit after consistantly locating and teleporting to structures(and every gc just makes it 95%→60%), making it unable to load chunks.
But after about 5 minites, everything goes back to normal.

To Reproduce
Steps to reproduce the behavior:

1. locate a structure
2. tepelort to it
3. locate another structure...

Expected behavior
Memory cleans up normally.

Screenshots
nah

Runtime info (please complete the following information):

• OS: windows 10
• Minecraft version: 1.19.2
• Mod version: 0.2.0
• Mod branch: (fill this if you are not using the default ver branches)

Crash reports / logs
https://gist.github.com/Rad233/d568ecceffd31783311775a78a9a9515

Other mods
suspects: fastquit, structure essentials
tell me if it needs more testing
https://gist.github.com/Rad233/68fd250401f1a7799dc19b8eb4bbb636

Checklist

• I am using the official version of the mod.
• I tried the latest development version but the issue persists.
• I searched for similar open issues and could not find an existing bug report on this.

Additional context
c2me config:
https://gist.github.com/Rad233/b31d43c0eacfca67dd54ead3186cd043
leak suspect report:
seems it can't be exported as pdf or something, so here're the pics.







question:
not sure how chunkDataCacheSoftLimit and chunkDataCacheLimit works, if it's too high/low, what would happen?

Please try reproduce with 1.19.4 or 1.20.1. 1.19.2 is no longer supported.

closed as no response

Result&conclusion:

1. In 1.19.2, with only c2me and fapi, the issue still happens(long saving time and memory leak).
2. Neither this issue is relating to java nor jvm flags.

1.19.2, shenandoah gc, zulu java 19
Log: https://gist.github.com/Rad233/34ca07c062712894e75b8c5fce7d9f8b
Jvm flags: -Xms8G -Xmx8G -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:AllocatePrefetchStyle=1 -XX:+SegmentedCodeCache -XX:ReservedCodeCacheSize=188m -XX:NonProfiledCodeHeapSize=80m -XX:ProfiledCodeHeapSize=96m -XX:NonNMethodCodeHeapSize=12m -XX:MetaspaceSize=320m -XX:+AlwaysPreTouch -XX:+UseNUMA -XX:+UseNewLongLShift -XX:+UseVectorCmov -XX:+UseFastStosb -XX:-DontCompileHugeMethods -XX:+UseCompressedOops -XX:+UseCompressedClassPointers -XX:+UseLargePages

1.19.2, g1 gc, oracle java 17
Log: https://gist.github.com/Rad233/2efbe7f35ce48e384a7db92bc724aced
Default jvm flags.

Mod config: https://gist.github.com/Rad233/f3bc35e9ef2dec48139746b1e51a8173

3. 1.19.4 version of c2me fixes the issue.

1.19.4, shenandoah gc, zulu java 19, same jvm flag
Log: https://gist.github.com/Rad233/82ca7bd015f24bda5304b7ef468f4421

1.19.4, g1 gc, oracle java 17, same jvm flag
Log: https://gist.github.com/Rad233/1da7dd4ac33e1d31f1a245f3bcc35241

so this issue should be closed since 1.19.2 is no longer supported, but, just a quick question: can i pay for a backport fix for 1.19.2?

Sorry, it's too time-consuming to provide that "heavily modded" environment in another version. But as far as i tested, no tick view distance is the cause of this issue, making the world taking extra time to quit, and the memory leak. Might be a clue to solve similar issues in 1.19.4 or 1.20.1.

The no-tick view distance has received a lot of fixes regarding saving times and memory pressure on 1.19.4 and 1.20.1. I doubt that is still going to happen on these versions.

Hmm, then it needs more testing. I'll try reproducing it in a cleaner environment and newer version.