Compiled Lucee classes getting re-compiled as new classes - and old ones not getting GCd

Description

Since upgrading from 5.2.x to 5.3.3-63, we find that our metaspace grows and grows as does the number of classes we have compiled.

We'd normally sit around 15,000 compiled classes, once upgraded to 5.3.3-62 the number just keeps growing. Typically we'll get an OOM Metaspace error at around 80,000 classes.

Examining a heap dump shows that around 60,000 of the loaded 75,000 classes in one instance were all compiled CFC/CFMs with multiple repeats. The below is a snapshot (they were not all this one .cfm file, there were many other .cfm and .cfcs present):

 

I believe this to be caused by the changes made in LDEV-2265.

I don't have more information to hand yet, but will be trying out reverting in a patch on our servers to see if the behaviour stops quickly or not. Hopefully should know in a day or so if it is indeed this change, the “leak” is pretty slow.


Environment

None

Activity

Show:
Brad Wood
March 11, 2020, 3:57 PM

I can't speak to the GC of classes specifically, but I CAN say that the recent snapshot builds on the 5.3.4 and 5.3.6 branches are MUCH faster. Measuring CommandBox reload times, it was taking around 40 seconds just to reload commandbox on 5.3.4.80 but going to 5.3.4.84 and now it's back down to <5 seconds where it used to be. 5 times faster! So something good happened there. Hopefully can chime in regarding the garbage collection issue.

Samuel W. Knowlton
March 11, 2020, 10:41 PM

I spent the better part of today on a repro case of this issue and it is largely the same thing Brad is talking about. It also goes away on 5.3.4.85 (though it went away on 5.3.5 and 5.3.6, too, only to be replaced with )

Michael Offner
March 20, 2020, 7:58 PM
Edited

we will soon reject the ticket, assuming no feedback is a good feedback.

Dominic Watson
March 20, 2020, 11:39 PM

The issue was resolved by reverting the changes made in the ticket LDEV-2265. I have since upgraded to the class loader behaviour in 5.3.5.80 and the issue is not appearing there.

As for rejecting it. Not sure why that would be the case. It absolutely is an issue and caused for us by the change in LDEV-2265. Changes since that are addressing other issues appear to have fixed it.

Michael Offner
March 23, 2020, 9:58 AM

we reject as duplicate because it already is addressed by an other ticket.

Duplicate

Assignee

Unassigned

Reporter

Dominic Watson

Priority

Blocker

Labels

Fix versions

None

Affects versions

Configure