template is bold
sample data is italicized

Issue Description: *
Paper has async chunk loading, that is performed by special threads, not by the server's thread, so planing chunk load blocks main server's thread and waits for paper's thread's response, causing lag spikes
Bellow is the spark profiler's report, and the code of paper that I think causes lag spikes, (because of paperweight i'm not sure if it's really it, but it should be the same logic, net.minecraft.server.level.ChunkMap)

Would be cool to implement better support for paper (maybe will help if "hard fork" will ever happen)

• Dynmap Version: core=3.4-beta-2-761, plugin=3.4-beta-2-761
• Server Version: git-Purpur-1586 (MC: 1.18.2)
• Pastebin of Configuration.txt: https://pastebin.com/CNDes9Up
• Server Host (if applicable): Contabo vps with pterodactyl
• Other Relevant Data/Screenshots: *
  
  
• Steps to Replicate:

1. Use paper, the core that is more than 90% used for 1.18.2 (source)

[x] I have looked at all other issues and this is not a duplicate (only until start of 2020, you have lots of closed issues)
[x] I have been able to replicate this

Going to go ahead and close this now since while it is not wanted behavior it is expected and "not a bug"

saw #2345 now, and idk if it's a dublicate or not, since there it unclear if it was implemented and now is broken, or it still wasn't implemented

Yep - it isn't. And it needs to be split so that the dependency on classes defined in Paper doesn't cause class loader errors when loading/resolving the methods/classes referring to them. Can be done, but isn't anything like '2-3 lines of code'

BUT, if you wanna do a PR that is tested and functional on all Paper and Spigot releases since 1.10.2, I'll be happy to accept it ;)

It wasn't implimented, it was placed in the Feature Request Megathread as either it needs someone more specific to help impliment it (also as we don't have a paper-specific-build but that is easier to set up) or isn't high on the feature list as we only really have one in-their-free-time dev.

A paper specific fork is beyond unlikely, and would not be supported. I can see if we could conditionally handle a subclass of the version specific code (which we need to do because the Spigot/Paper API is quite inadequate and has long standing bugs that prevent its use - specifically around the disfunction of the 'no-generate' behavior in the chunk APIs since 1.13.2, and the perpetual lack of NBT access), but it will be a question as to whether it is worth the extra testing and support on our part.

I think it's worth it, because most servers use paper, or paper forks, a lot more than spigot, and in that case, it's only a question should be this code run on server, or async on your threads, so I can see 1 simple solution:

1. store a static final boolean variable if paper is available
2. the callables that on paper would need to wait for paper threads, are stored in a variable
3. if it's paper, the callable runs on the same thread, if it's not, the callable is sent to scheduler

That would add like 2-3 lines of code in such places, just need someone who knows where that wait can happen

or, after seeing the code, seems like not that easy

BUT, if you wanna do a PR that is tested and functional on all Paper and Spigot releases since 1.10.2, I'll be happy to accept it ;)

well, i might try if on my easter school holiday i'll have free time, i really like this plugin so i think it will be an useful experience to make that pr

but even if i'll make it, i think i would make it only for latest version, but without breaking old versions, i don't think i'll have enough time to make for all versions

Going to go ahead and close this now since while it is not wanted behavior it is expected and "not a bug"

oh, yeah, also my pr fixed this, so totally good