I'm going to be honest; I'm not 100% sure how to report this. I'm seeing some pretty crazy memory use from what appear to be your FXWisp and FXSparkle particles.

How can I help you help me figure out what's happening here? This is a heap dump from a client.

You're absolutely grasping at straws here @suirad. That is not in minutes, it's in ticks. All that expiring the particle does is remove the particle from the particle emitter queue, leaving it with no strong reference, and then it can be GC'd.

Aside from the references present in Minecraft's inner particle queue, the only other strong reference is kept in a queue inside each of the particles' classes, which is cleared every render tick.

I honestly have no idea what can be causing this.

Like mentioned, it was a surface level review. Only trying to assist you or
any other looking to debug. Although I wouldn't say my analysis isn't
completely unfounded as it seems something is happening to prevent
collection of those objects.

On Tue, Oct 11, 2016, 10:17 AM Vasco Lavos [email protected] wrote:

You're absolutely grasping at straws here @suirad
https://github.com/suirad. That is not in minutes, it's in ticks. All
that expiring the particle does is remove the particle from the particle
emitter queue, leaving it with no strong reference, and then it can be GC'd.

Aside from the references present in Minecraft's inner particle queue, the
only other strong reference is kept in a queue inside each of the
particles' classes, which is cleared every render tick.

I honestly have no idea what can be caused this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#265 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIZCbc_ugv4-kSpsHF11aR2IbRL7NzHvks5qy6h1gaJpZM4KTHjZ
.

After a quick review of a9f46a0, I don't see anywhere where the particle objects are explicitly dereferenced after use. I am not super familiar with the mod/modding internals, but it seems like those objects aren't expiring correctly, based on the profile above.
FXSparkle seems to have a 3 minute expiry time(seen here), which I cannot imagine to be justified for a single particle.
FXWisp also has a variable max age which could also be subject to extremely long gc times; seen here.

Removing every conjured block/light has fixed this issue; is there an option to prevent their use while this is investigated?

I think there's a config to diable certain components. Correct me if I'm mistaken

@InjuredWolf Unfortunately, the PSI config only has 9 options in 1.10.2 and none of them disable conjured lights/blocks.

@Alaberti requesting another test?

Is this fix in an update that's already available? Sorry for the delay.

No, it will be later today. You could build from source if you wanted, but we'll be ready for testing soon.

That's the fun part about life - live, learn, and bury the evidence.

Like what just happened there.

Testing now!

I got a crash with the following: Forge 14.23.5.2806, psi r1.1-65, autoreglib 1.3-24, completely fresh install, downloaded from curseforge. Crash report: https://pastebin.com/zGAudhg7

Thanks, rerunning the test now.

I don't know what you did, but this is significantly better - the rate of memory usage is now completely in-line with vanilla memory usage as opposed to crashing minecraft after about a half hour. I would consider this a fix.

So, going back over my changes to the code, and then several pieces of native Java code and JVM documentation, I found the reason it was happening.
I regret doing so.

It seems that, somehow, because the ArrayDeque was internally untyped (no diamond operator), it was creating arrays which were being held in memory in a nonstandard way due to how they were being cast and copied, causing them to... never be dereferenced. Ever.

Yep.

I'm just going to walk slowly away from that.

This bug is still present.