I found a memory leak in the most recent 2 versions of this mod. I updated to 2.0.5 the other day and since have needed a whopping FIFTEEN GB of RAM to load my 44MB world. Backdating all the way to 1.8.0 fixes this leak, as far as I know. It may also be a severe mismanagement of RAM, since your new system parses through lots of things on larger modpacks I think. It may not be viable to use that system for compatibility if it produces this kind of effect. I know most players are lazy and won't customize their game, but disabling the recipes and items that are technically duplicates of vertical slabs is not hard nor does it take a while.

I tested in descending order from the latest version after finding that 1.8.0 let me load the world, the last version that doesn't have this issue is: 1.8.0 (2.0.1, 2.0.0 gave me repeated null crashes). This is all running JDK 17.0.8 according to my heapdump data (I couldn't figure anything else out from it, I've never read a heapdump summary).

This may be due to a mod conflict, since I've been using several of these versions for months in this modpack, but I'm not sure why it'd suddenly manifest like this. This only started happening after I tried upgrading my JVM runtime to jdk 21/graalvm 17/21, only after trying that did all worlds start sucking RAM and hammering my CPU. The game can't even render properly when trying to load worlds, and will black out during freezes. I also notice that ingame with 15GB, the RAM allocation is constantly hitting the buffer cap and the GC produces, predictably, a large amount of hitching. Seems like something is gobbling RAM and not letting up, and I also note that it follows memory leak patterns by getting worse gradually as a session continues.

Since backdating this mod resolves the loading RAM issues, I figure it's also causing severe issues ingame.

My logs show nothing of importance, I forgot to mention. There's no crashing, no memory warnings or errors relating to Additional Placements at all. This took a combined 15 or so hours of troubleshooting to find.

Assuming you use a launcher like multiMC, polyMC, or prismMC, please export the instance and send the zip file. Otherwise, manually zip the mods and config folder and send that.

The only thing I can think of is if another mod is creating new blockmodel instances repeatedly instead of re-using old ones, causing my blockmodel caches to balloon in size.

I didn't think of that, thanks for reminding me. I will note that I have done months of extensive bugfixing and compatibility testing on this pack via batch methods. I've missed a clear memory issue many many times despite trying. As far as I can tell it's hidden behind the size of my modpack and that's why it was hard to find in other troubleshooting sessions for unrelated issues. I also don't know how to read heapdumps or spark too well, so finding the mechanisms that constitute a leak like this are kind of beyond me, otherwise I'd do that for you :/

There are normally several thousand errors relating to models being unable to be found, your hunch could be spot on.

Know that there are a few known errors that I've chosen to ignore, since this modpack is for me alone and functions well enough otherwise. I've ruled them out as culprits for lag and whatnot, they only really crash the game at startup sometimes.

Compressed folders

well the reason I wanted the instance is I can make custom mod builds that insert debugging systems to do stuff like counting the number of cached models, whether a blockstate continues to generate new models when it shouldn't be, ect.
The good thing is I want to completely redo how my block model wrappers are created so that they don't need to be done in the shaper, to improve compatibility, which would negate the cache requirement entirely anyway.

I'm glad I understand just enough to get how epic that is, geez. That's sick af.

Also, does your system disable the additional slab block from AP or does it disable the "duplicate" from any mod that adds vertical slabs? The latter seems more efficient and ergonomic for end usage, but the way you worded the changelog makes me think it works in the former way, and that confuses me.

I can't disable blocks from other mods. I'm not sure what you meant by "worded the changelog", if you could point out which part of it you're talking about I can explain it more thoroughly.

I must have misread something somewhere, I thought it was weird then too since only data can do that easily.

Well I've tested my local changes that redo the entire model system and while it is loadable and doesn't seem to have any memory leaks, it does take an absurd amount of RAM to load into a world.
I can launch the game on as low as 8GB of RAM but then I need to have 16GB of RAM to actually load a world.
I honestly don't know what in my mod could possibly be causing this.

I'd have blamed it on generating tons of BakedModel instances but that would cause memory usage during client resource loading - which happens during startup, not during world loading. I also checked my voxelshape cache (which is a weakmap so that it won't cause memory leaks) and that wasn't the issue either.

The only change I can think of that could be increasing the memory usage this much would be if ANOTHER mod has a memory leak related to blockstate count, and the increase of blockstates for stairs (from 60 additional placements to 320 additional placements) exacerbated the issue to the point it became noticable

My pack functions ayokay in-world with less than 10GB when it doesn't need 15GB to load. Having AP loaded causes ingame RAM to balloon after initial world load, period. It doesn't go back down and continues to hit the buffer.

Are you talking about block types like stairs and slabs? Could look up stair/slab in JEI and multiply by page-count -1, then add up the last page because it won't be full. I shouldn't have more than 30 extra total, I don't think. Are you aware of any issues with block registration for Copy Cats +? It doesn't get the AP treatment, so might freak out? Could be TFMG, it has odd issues, but I don't think they're registration related.

wish there was a way to see how many of any specific object exists inside the java runtime, maybe there is a tool for that.

Really I just don't know what's causing the memory usage to balloon so much during world loading. The chunk data itself should use that much RAM unless you have tons and tons of entities and block entities, the other data loaded here would be datapack stuff like block tags, nothing that should use gigabytes.

Well you should see if the latest version at least works better and doesn't degrade performance over time. I can't really be sure how it'll run for most users as most people aren't rocking 64GB of DDR4-3600.

Will do, may get to it tomorrow. I had a severe registry corruption last week and only just got back online. 6mo old backup :/ I did recover necessary files for my stuff though. Thanks for updating this thread. I wouldn't be surprised if there's a mod with an issue to the extent you describe, I've seen more and more very silly issues with mod block registration recently. I'll try to sus it out.

So I'm inspecting the heap with VisualVM and literally almost 30% of the used memory is just from ImmutableMap stuff.

I have no clue why and what that means. I also saw that in my heapdump

Well it's already closed, they "don't backport to older versions." The rest of the reason is salty as fuck, so Idk about contacting them ever. I think they also misunderstood the assignment, can't tell through the salt.

What I'm saying is that I've been running this modpack, including WE, for more than a month with no RAM issues. 2 weeks ago is the first time I encountered this issue in any sense. Why is the previous update the one that tipped it over the edge for all versions after 1.8.0? I understand that there are more states, but I was using 2.0.5 well beforehand.

I also should link this in the WE github I guess, they might have an explanation or be interested in a bug.

Yes. 2.0.5 was working, but backdating from 2.0.8 broke everything back to 1.8.0.

I was using 2.0.5 well beforehand.

So you mean to say that 2.0.5 was working originally, and suddenly stopped working? that would be odd.

well yeah, 1.8.0 doesn't know anything about the 2.0.0 blockstate changes. I'm a bit confused, as your original post states the issue started after updating to 2.0.5 though, and that all previous versions had the same issue.

To clarify: I was most likely on version 2.0.5 when it broke, and tested 2.0.8. Before that, I was absolutely running 2.0.3 and back to 1.8.0, since this pack has been in dev since August.

I found the culprit! It's WorldEdit. For some reason it uses up a TON of RAM for every single blockstate in the game. Removing it allowed me to load not only just fine with only 8GB of RAM allocation, but also a lot faster than when I was loading with it on 16GB.

The reason you were still able to load with 1.8.0 is because the stair states were much simpler - only 4*15 (60) additional placements, as opposed to 8*40 (320). you must have been skirting just under the limit before, but adding in the >260000 new blockstates from the increased stair states (~500 stair blocks * (320 - 60) new placements * 2 (with and without waterlogging)) pushed it well over the limit.

Omg and I had just added it recently for building. That sucks a ton actually lmao. It's unplayable at 15GB because of the GC lag, even with more aggressive java runtimes to curb it. And I guess this isn't a "bug" per se, but an unfortunate intended feature for the functionality of WE. Hrm...

My solution for now is to build with 1.8.0, and remove WE when my project is ready for survival. Will that pose any issues with updating from so far back? I do have other building tools, but some things are simply impossible without WE.

Thanks for sussing this out. I wonder if there's a way to make the math better somehow. It's kind of basic already, so volume is really the big issue. I assume that means this is a Java limitation, not necessarily the game?

Edit: I do wonder why this wasn't a symptom right away though. I've had WE installed for about a month and only last week-ish did it begin to do this; I was previously running on 9.5GB just fine.

It hopefully won't but there's a chance that chunks may get reverted. there's an issue in my code to convert the blockstates from 1.8.0 into 2.0.0+ that sometimes does that but IDK what it is.

Edit: I do wonder why this wasn't a symptom right away though. I've had WE installed for about a month and only last week-ish did it begin to do this; I was previously running on 9.5GB just fine.

Like I said, it's because of the huge increase in blockstate count. Note that for just 500 stair blocks (you have more than that) there's more than a quarter of a million additional blockstates compared to 1.8.0. It could be even more than that, if some of those stairs have more non-placement state properties (besides the boolean isWaterlogged)

not surprised they don't provide support for older versions, but hopefully that means they already have the issue fixed in newer versions

I meant specifically uninstalling the mod completely so I can build with WE, then uninstalling WE, reinstalling AP and building from there to eliminate the issue in the meantime. WE is the problem, I think, and there's not a lot of ways to reduce it without completely eliminating some important parts of the modpack.

In respect to updating from 1.8.0 to 2.+ being problematic, are there also problems installing the mod on a preexisting world?

possibly? I'm really unsure of what the issue is, it vaguely popped up for me once in my MDK but didn't contain enough information to figure out what happened. I need a way to reliably reproduce it.

Well the latest version will have heavily reduced the number of blockstates for most vertical stair blocks - not quite to pre-2.0.0 levels, since I retain the split from "inner" to "inner_front", "inner_top", and "inner_both", but it's still less than half of what 2.0.0 was doing. It might work for you now. I also fully tested the blockstate version upgrader and can confirm it does work properly now, whereas before it sometimes gave the wrong shape or orientation.