Justenoughitems: [1.12.2] JEI using up way too much RAM

[samantharachelb]

Hi there,

I've been using _trying to_ use JEI in a mod pack that I've put together, and it's eating up RAM faster than Chrome with a hundred tabs open.

Prior to adding JEI to the pack, I was able to run the 100+ modpack with 8GB of RAM without any issues. Since adding JEI to the pack, I'm unable to get past [jei]: Building ingredient filter. I was _barely_ able to get it to load once I allocated 30GB of RAM, but having to load allocate 30GB of ram just to get JEI to load seems a little excessive to me, considering that some of the friends I'm playing with have a max of 16GB.

I've tried suggestions from issues #746, #1836, and #1581

Disabling VSync as suggested in #746 and #1581 did not resolve the issue. Adding JVM arguments as suggested in #1836 didn't resolve the issue, and neither did disabling colorSearch in the jei config as suggested in #1581.

Machine Specs:

• CPU: 16x Intel(R) Core(TM) i9-9880HK @ 2.40Ghz (8 phys. cores, 16 threads)
• RAM: 32GB (2400 MHz DDR4)
• GPU: AMD Radeon Pro Vega 20 (4GB HBM2)

Versions:

• Minecraft: 1.12.2
• Forge: 1.12.2-14.23.5.2847
• JEI: 4.15.0.291

JVM Arguments (Client 8G):
-XX:+UseConcMarkSweepGC, -XX:+DisableExplicitGC, -XX:+CMSParallelRemarkEnabled, -XX:+UseBiasedLocking, -XX:SurvivorRatio=90, -XX:ReservedCodeCache=4096m, -XX:ParallelGCThreads=12

JVM Arguments (Client 30G):
-XX:+UseConcMarkSweepGC, -XX:+DisableExplicitGC, -XX:+CMSParallelRemarkEnabled, -XX:+UseBiasedLocking, -XX:SurvivorRatio=90, -XX:ReservedCodeCache=15360m, -XX:ParallelGCThreads=12

JVM Arguments (Server 12G):
-XX:+UseConcMarkSweepGC, -XX:+DisableExplicitGC, -XX:+CMSParallelRemarkEnabled, -XX:+UseBiasedLocking, -XX:SurvivorRatio=8, -XX:ReservedCodeCacheSize=2048m, -XX:ParallelGCThreads=8, -Dfml.readTimeout=90

When loading with 8GB allocated, I get the error: java.lang.OutOfMemoryError: Java heap space.

When loading with 30GB allocated, it takes anywhere from 30-45 minutes just to load.

Once I do get it to load, connecting to a server is next to impossible because loading JEI causes a timeout.

[StargateMC]

+1 to this.
Our clients get murdered, crashing after they attempt to connect to any server or load Single Player with 60 mods installed.

We see the following entries in the debug.log file:

[22:51:53] [Client thread/WARN] [jei]: Mod added a tree entry after memory optimization!
java.lang.UnsupportedOperationException: null
at it.unimi.dsi.fastutil.chars.AbstractChar2ObjectFunction.put(AbstractChar2ObjectFunction.java:119) ~[AbstractChar2ObjectFunction.class:?]
at mezz.jei.suffixtree.Node.addEdge(Node.java:124) [Node.class:?]
at mezz.jei.suffixtree.GeneralizedSuffixTree.update(GeneralizedSuffixTree.java:335) [GeneralizedSuffixTree.class:?]
at mezz.jei.suffixtree.GeneralizedSuffixTree.put(GeneralizedSuffixTree.java:166) [GeneralizedSuffixTree.class:?]
at mezz.jei.ingredients.IngredientFilter.addIngredient(IngredientFilter.java:119) [IngredientFilter.class:?]
at mezz.jei.ingredients.IngredientRegistry.addIngredientsAtRuntime(IngredientRegistry.java:277) [IngredientRegistry.class:?]
at mezz.jei.ingredients.IngredientRegistry.addIngredientsAtRuntime(IngredientRegistry.java:222) [IngredientRegistry.class:?]
at mezz.jei.ingredients.IngredientRegistry.addIngredientsAtRuntime(IngredientRegistry.java:229) [IngredientRegistry.class:?]
at li.cil.oc.integration.jei.ModJEI$$anonfun$addDiskAtRuntime$1$$anonfun$apply$1$$anonfun$apply$mcV$sp$1.apply(ModJEI.scala:27) [ModJEI$$anonfun$addDiskAtRuntime$1$$anonfun$apply$1$$anonfun$apply$mcV$sp$1.class:?]
at li.cil.oc.integration.jei.ModJEI$$anonfun$addDiskAtRuntime$1$$anonfun$apply$1$$anonfun$apply$mcV$sp$1.apply(ModJEI.scala:27) [ModJEI$$anonfun$addDiskAtRuntime$1$$anonfun$apply$1$$anonfun$apply$mcV$sp$1.class:?]
at scala.Option.foreach(Option.scala:245) [Option.class:?]
at li.cil.oc.integration.jei.ModJEI$$anonfun$addDiskAtRuntime$1$$anonfun$apply$1.apply$mcV$sp(ModJEI.scala:27) [ModJEI$$anonfun$addDiskAtRuntime$1$$anonfun$apply$1.class:?]
at li.cil.oc.common.EventHandler$$anonfun$onClientTick$1.apply(EventHandler.scala:239) [EventHandler$$anonfun$onClientTick$1.class:?]
at li.cil.oc.common.EventHandler$$anonfun$onClientTick$1.apply(EventHandler.scala:238) [EventHandler$$anonfun$onClientTick$1.class:?]
at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:33) [IndexedSeqOptimized$class.class:?]
at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:186) [ArrayOps$ofRef.class:?]
at li.cil.oc.common.EventHandler$.onClientTick(EventHandler.scala:238) [EventHandler$.class:?]
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_636_EventHandler$_onClientTick_ClientTickEvent.invoke(.dynamic) [?:?]
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90) [ASMEventHandler.class:?]
at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:182) [EventBus.class:?]
at net.minecraftforge.fml.common.FMLCommonHandler.onPreClientTick(FMLCommonHandler.java:344) [FMLCommonHandler.class:?]
at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1708) [bib.class:?]
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:1098) [bib.class:?]
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:398) [bib.class:?]
at net.minecraft.client.main.Main.main(SourceFile:123) [Main.class:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_111]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_111]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_111]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_111]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?]

We also see this after logs show the above many times:

[22:52:13] [Client thread/FATAL] [net.minecraft.client.Minecraft]: Error executing task
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(Unknown Source) ~[?:1.8.0_111]
at java.util.concurrent.FutureTask.get(Unknown Source) ~[?:1.8.0_111]
at net.minecraft.util.Util.func_181617_a(SourceFile:47) [h.class:?]
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:1088) [bib.class:?]
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:398) [bib.class:?]
at net.minecraft.client.main.Main.main(SourceFile:123) [Main.class:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_111]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_111]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_111]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_111]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?]

[samantharachelb]

It should be worth noting that I have also tested this issue with the default Minecraft resource pack.

Memory usage before [jei]: Building ingredient filter: ~4.5 Gb
During the ingredient filter build process, memory usage climbs well past 8 Gb, and this is before textures are even loaded.

At this point I'm sort of stuck in a bind because NEI requires JEI as a dependency so I'm forced to either bundle the two together or drop NEI from the pack which is something that is wildly unpopular with the modpack users.

[jadenquinn]

They mezz has a history of ignoring this issue and telling us players that it's our problem. I will not take that for an answer. I'm sorry.

[StargateMC]

Still need to respect the fact your not a paying customer... being confrontational will just piss the author off.

[stale[bot]]

This has been automatically marked as stale because it has not had recent activity, and will be closed if no further activity occurs. If this was overlooked, forgotten, or should remain open for any other reason, please reply here to call attention to it and remove the stale status. Thank you for your contributions.

[stale[bot]]

This has been automatically closed because it has not had recent activity. Please feel free to update or reopen it.

[sor1n]

I want to revive this and simply ask for a config option to remove the recipe search function of the mod. That should drastically reduce the memory usage. Sure, you won't be able to look for the recipe of set object, but having all blocks and items visible in one menu, rather than having to frantically look in the creative menu for said block/item, is much better. Just the simple ability to search by mod or NBT data is 100% better than the creative search menu.

[mezz]

Thanks for the report!
This may be caused by a mod adding recipes to JEI very late, breaking some optimizations that were added.

@asiekierka it looks like players are hitting the Mod added a tree entry after memory optimization! log. Could you follow up with the mod causing this?

[asiekierka]

at li.cil.oc.integration.jei.ModJEI$$anonfun$addDiskAtRuntime$1$$anonfun$apply$1.apply$mcV$sp(ModJEI.scala:27) [ModJEI$$anonfun$addDiskAtRuntime$1$$anonfun$apply$1.class:?]

OpenComputers is, in this specific log.

[otakup0pe]

at li.cil.oc.integration.jei.ModJEI$$anonfun$addDiskAtRuntime$1$$anonfun$apply$1.apply$mcV$sp(ModJEI.scala:27) [ModJEI$$anonfun$addDiskAtRuntime$1$$anonfun$apply$1.class:?]

OpenComputers is, in this specific log.

Huh. Came here bc of the Mod added a tree entry after memory optimization! error message and in my case it is _also_ OpenComputers. Not seeing the wild memory spike though (that I noticed).

[Dimentive]

What’s the status on this issue?

[mezz]

@Dimentive Please follow the OpenComputers issue for any updates: https://github.com/MightyPirates/OpenComputers/issues/3223