Mircea, please look for some natural ways to re-use objects in the servlet stack. Art has performed memory analysis as follows:

The memory spent per session in classes of the package com.icesoft.faces.webapp.http is 37,096 bytes in retained size (1,272 in shallow size). Note that we are including an instance of ServletExternalContext, which extends BridgeExternalContext from the context package. If we didn't count this object, the size would be 5,864 bytes per client.

There are 8 instances of PathDispatcherServer$Matcher per session, plus 7 more for the whole app. The retained size of these objects ranges from 232 to 368 bytes.

The only object retained by PathDispatcherServer$Matcher is a regex pattern. We seem to be keeping in memory a whole set of regex patterns per client. So, this is a place where we could save some memory if we use the same compiled regex pattern for all clients. However, I don't know if it's necessary to have different regex patterns per client. For example, if the pattern must contain some random id generated for that client.

I looked into the source code and the constructor of PathDispatcherServer$Matcher takes a String which is used to compile a regex pattern instead of just taking a pre-compiled pattern.

The number of PathDispatcherServer$Matcher instances are determined by how many paths are defined, configured and hardcoded, in our code. Even if some of compiled regex expressions would be shared as static fields it will not bring any memory gains.

The size of an object instance is proportional with the number of instance fields it has (when fields are object references, not primitive types). The rule does not apply to special objects like String or Array.
So if we want to reduce memory we should look at objects with lots of instance fields or lots of instances with a few instance fields.

I'll look through the code to see what areas are good candidates for a memory-conscious re-factoring.
As an example, for a long time I wanted to bring EnvironmentAdaptingServlet in front of the SessionDispatcher so that the detection is done per application, not per session how is it done now, thus instantiating only one EnvironmentAdaptingServlet object.

Servlet re-ordering sounds even better. The Matcher instances stand out because in a test of auctionMonitor with 120 users there are

965 instances of class com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer$Matcher

Refactored for better memory usage....not the most elegant solution but is efficient.