We run in Wildfly 26.1 and have these three classes that triggered an OOM due to having a CreationalContextImpl that tracks 9M dependentInstances.

First the code structure (the implementations of the methods seem not related):

@Stateless
@TransactionAttribute(TransactionAttributeType.MANDATORY)
public class LogDAO {
	@Resource(mappedName = "java:/datasource/logs")
	private DataSource dataSource;

	@Asynchronous
	@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
	public void saveLog(Long organisatie, Long account, String main, String menu,
			String contextType, Long contextId) {
                // do something with database
	}
}

The saveLog method is used asynchronously so this doesn't hold up normal request processing. This EJB is injected into an application scoped bean:

@ApplicationScoped
public class Logger {
	@Inject
	private Instance<LogDAO> logDAO;

	public void log(MainMenuItem item, MenuItemKey key, Entity contextObject) {
		// do something with arguments
		logDAO.get()
			.saveLog(organisatie, account, main, menu, contextType, contextId);
	}
}

And this is injected into each page instance in an Apache Wicket application:

public abstract class SecurePage extends WebPage {
	@Inject
	private Logger logger;

	protected void onInitialization() {
		logger.log(getSelectedItem(), selectedMenuItemKey, context);
	}
}

For information: the pages do get serialized and deserialized due to the nature of Wicket, if that is of help, so the logger field of the SecurePage will be serialized (as a proxy of course), but not the Logger instance itself, nor should the serialization process touch the Instance<LoggerDAO> field of the Logger.

This apparently causes over time a CreationContextImpl that tracks 9M LogDAO$Proxy$_$$_Weld$EnterpriseProxy$ objects as can be seen from the attached screen shots. This resulted in 12.9GB of retained memory and caused our server to fail.

Probable cause

The thing that was recently changed is that the field definition of the logDAO field of the Logger class was modified from being a direct reference to currently an Instance<LogDAO>.

We suspect that the Instance<LogDAO> somehow triggers the tracking of the 9M of dependentInstances. But we don't have a reason for that, other than the change to Instance and the asynchronous call?