Hi Nathan, a) In the original code, a new copy of string image is constructed and returned as part of the token, which is part of a node. When we cache templates, these nodes stay in memory forever or until the template itself is booted from the cache. We improved this by checking against the string image pool. If the image already exists in the pool, the reference for the image is used instead of the newly created string. The newly created string will be garbage collected.
b) This image pool is being called constantly and that's why we don't want to synchronized on the get call. It is okay to have one thread overwrites the other's string image and the overwritten images won't be lost if there could be existing references to them. Thanks. -- Lei Velocity - Dev mailing list-2 wrote: > > > [ > https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486064 > ] > > Nathan Bubna commented on VELOCITY-223: > --------------------------------------- > > Those are great numbers! I'm excited to have a such potential boost to > our velocimacro memory performance! Still, i have two questions... > > a) Why does this work? Clearly, i'm ignorant of the inner workings of the > String class! I'd never have thought to try something like this. This is > mysterious to me; i'd love to learn why this works. > > b) What good is the synchronization around the call to > stringImagePool.put()? If we're concerned about stringImages stomping on > one another, shouldn't we just use Hashtable or synchronize the whole > method? > >> VMs that use a large number of directives and macros use excessive >> amounts of memory - over 4-6MB RAM per form >> -------------------------------------------------------------------------------------------------------------- >> >> Key: VELOCITY-223 >> URL: https://issues.apache.org/jira/browse/VELOCITY-223 >> Project: Velocity >> Issue Type: Bug >> Components: Engine >> Affects Versions: 1.3.1 >> Environment: Operating System: All >> Platform: All >> Reporter: Christian Nichols >> Fix For: 1.6 >> >> Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, >> StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG >> >> >> Our application FinanceCenter is based on Velocity as the template >> engine. We >> have a library of about 200 macros and about 400 VM files. Because the >> velocity parser copies the macro body into the VM during parsing, macros >> that >> are frequently used (even though identical and using local contexts) use >> up >> large amounts of memory. On our Linux server (running Redhat 7.2 with >> Sun JDK >> 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many >> forms >> (about 150) - the server starts out using 60MB after startup. This >> memory >> times out after 5 minutes and is returned which tells me that it is >> screen >> memory. Our problem is that the NT JVM and Linux JVM (32 bit) are >> currently >> limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair >> number >> of forms in the application leaves little space for user session data. >> We have implemented a caching mechanism for compiled templates and >> integrated >> it into Velocity so that cached objects are timed out of the cache but >> the >> server is still using large amounts of memory. We finally had to rewrite >> many >> of our macros into Java so that memory usage would be reduced (note that >> these >> macros were doing complex screen formatting not business logic). Doing >> this >> has reduced our memory by about 30%. This is currently our biggest issue >> with >> Velocity and is causing us to review our decision to stay with Velocity >> going >> forward. This is because we will likely end up with close to 1,000 forms >> by >> the end of next year and need to know that Velocity can deal with this. >> Is >> there any work underway to share compiled macro AST's? This would >> greatly >> reduce the amount of memory used. I have reviewed the parser code that >> is >> doing this but it seems that this is an embedded part of the design and >> not >> easily changed. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/-jira--Commented%3A-%28VELOCITY-223%29-VMs-that-use-a-large-number-of-directives-and-macros-use-excessive-amounts-of-memory---over-4-6MB-RAM-per-form-tf3506788.html#a9796510 Sent from the Velocity - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
