Chunk Locking is Slow under harsh conditions

[KubiRemPL]

Hello Ur mod is great but i found some bug in it all threads are stuck on 20% of utilization and cannot go further but tps is going lower lower and lower because of this lock. Here is the example of lots of tile entites.

Btw I am making a profesional video about Ur great mod. Will show all guys that say "minecraft is single core only!!!" cuz it can be multi-core with this mod but this lock really block this mod capabilities. Keep it up!!!

Best Regards KubiRemPL

[jediminer543]

Hi, can you give me your put your debug.log file up on a paste site please?

This kind of issue is typically caused either by:

• Something I've protected using synchronized being needed in parallel access
• Something getting stuck in an error loop (and consequently the game churning as threads are de-instantiated and re-instantiated)

However it's hard to diagnose what causes stuff like this without log files

Thanks

[KubiRemPL]

Sorry but hastebin and pastebin cannot paste it (it's too large). I will send raw file. debug.log Thanks for fast replay!!! I am using Mekanism solar panels and batteries to test load on server btw.

[jediminer543]

Thanks; I forgot you could just put files straight into issues (am derp)

Ok, that's really odd; there are no exceptions

I'll spin up a test environment and see what I can see;

Just to confirm, you are using:

• Minecraft 1.15.2
• MC Forge 1.15.2-31.2.36
• Mekanism 1.15.2-9.10.9.422 (+MekanismAdditions,+MekanismGenerators)
• RealisticTorches 1.15.2-3.0.0
• worldedit-forge-mc1.15.2-7.1.0
• jmt_mcmt-1.15.2-0.14.34

Thanks

Also, if you want to help with debugging, could you try launching the world with just forge and mcmt and see if the issue persists? (then maybe go through and try re-enabling mods and see if one of them is causing the lag spikes);

It's possible it's a vanilla interaction; but it seems more likely that it would be a mod based one.

[KubiRemPL]

Yeah I am using these mods. I will try with vanilla furnances and see if it happens.

[jediminer543]

I mean vanilla furnaces would be a better test as by default config modded TE's aren't fully multithreaded as some of them get REALLY upset about being multithreaded (as they use the same library as minecraft core (FastUtil) which hates multithreading). If you want to much around with this you need to run /mcmt config temanage target whitelist (be aware this needs OP permissions (i.e. cheats on in single player))

From the bug standpoint:

However: I can't seem to replicate what the issue is

Modlist (the (1) is from where I've downloaded the mods before as for this test I just pulled a clean copy off Curse):

Any chance you could throw me the world to see if it's an in world issue? (sorry for the long debugging process)

[KubiRemPL]

Ok I am making a new world and send U it with the setup. Be aware that there is ALOT of tile entites I mean it's for sure not real scenario I just wanted to stress test

[KubiRemPL]

world.zip There is this world. It looks like I am getting worse performance with this mod in this scenario.

[jediminer543]

Ok, for a demonstation in that scenario:

• Enable cheats
• Fly up to the structure, look at an energy cube and run /mcmt config temanage target whitelist; You should see:

  Added mekanism.common.tile.TileEntityEnergyCube to TE Whitelist

• Do the same for the solar panels; you should see

  Added mekanism.generators.common.tile.TileEntitySolarGenerator to TE Whitelist

• You can do the same with the universal cable if you want, but that's the one that's most likely to break

I can't like guarentee that this wil be safe (as I'm avoiding doing anything other than saying "this appears to work" or "I'll patch that massive bug", but I've not seen any errors yet in testing:

BTW if you are curious as to why there is so much of a performance change; under the default configuration; modded tile entities are handled on a chunk locking system as under normal use cases it should allow for reasonable parallelism;

Basicly as we know stuff like cables/machines/etc. normally have a limited interaction range (which I assume by default to be 1 chunk and need to add a config for); So I use concurrency locks to ensure that as far as that tile entity is concerned, it is running in all by itself. However, concurrency locks do have overhead, and I'm guessing under this scenario those overheads are starting to show.

I'll add this to the "to optimise" list

[KubiRemPL]

Thanks so much. I will show U my video when I am done.

[jediminer543]

Thanks, that'll be nice

I've also found a hotspot in the code that I'll poke at and try and fix (the bulk of that parallelised tick time is being spent with all the energy cubes fighting to see what tile entities are around them as that is currently a synchronised mehtod); I'll have a look into optimising that away as well

Edit: Something else I should say; if you want to do the whitelisting beforehand, make sure to run /mcmt config save afterwards so it's persisted to the actual file config;

Edit2: Please note that this appears to cause world loading issues for me (which is one of the issues with messing with modded TEs); they behave differently on world load to during runtime