If you're lucky, and by lucky I mean smart, you have FusionReactor installed on your server.  The breadth and usefulness of the information afforded by the tool (especially when it comes to memory and garbage collection) is lost on most who use it.  On some occasions you may find yourself needing to pull some memory numbers on an old server (or maybe just someone else's server) who doesn't have any tools installed.  I found myself in this situation the other day when tweaking an old legacy server.  It's sharing 1GB of ram between CFMX7, Railo, Apache, MySQL, and Linux.  It actually operates pretty good on so little memory.  After converting a couple of the legacy sites over to ContentBox which utilizes ORM and in-memory caching for performance I needed to tweak the heap space to be a bit bigger in Railo but I needed to decrease something else to make room. 

Now, this old server doesn't have FusionReactor installed, but it does have SeeFusion and while that tells me the usage of my heap space it doesn't show me the amount of permanent generation that's in use.  Remember, perm gen is stored outside of heap so the total memory footprint  of CF will roughly be heap + permgen.  (Of course, that comes with a few caveats, namely that you're actually using a JVM with a permanent generation!)

I wanted to trim down the perm gen space on CF and Railo to make room for a bigger heap.  I knew what the starting and max perm gen sizes were from my -XX:PermSize and -XX:MaxPermSize JVM args, but I didn't know how much of that was actually being used!  Of course, I could enable verbose GC logging, but that's a lot of work to parse through and I would have to restart the server and wait for the JVM to "warm up" again.  Instead I used a Java class called ManagementFactory.  This class will give you stats on each of your memory spaces in including your new and old generations (part of the heap).  Based on your JVM and your garbage collector in use, you will see different names for the memory spaces, but this bit of code will get you started to see how many MB of space are currently allocated and how much of that allocated space is in use.  Keep in mind that perm gen is not typically garbage collected, so once it goes up you won't see it go down.

<cfscript>
iter = createObject("java","java.lang.management.ManagementFactory").getMemoryPoolMXBeans().iterator();
while (iter.hasNext())
{
    item = iter.next();
    name = item.getName();
    type = item.getType().toString();
    used = item.getUsage().getUsed()/1024/1024;
    max = item.getUsage().getMax()/1024/1024;
    
    writeOutput("#name# (#type#)<br>");
    writeOutput("#round(used)#MB / #round(max)#MB <br><br>");
}
</cfscript>

Here is the output from my local CF10 install.

Code Cache (Non-heap memory)
5MB / 48MB 

PS Eden Space (Heap memory)
82MB / 150MB 

PS Survivor Space (Heap memory)
6MB / 92MB 

PS Old Gen (Heap memory)
363MB / 683MB 

PS Perm Gen (Non-heap memory)
83MB / 512MB

Try dumping out the Java object that comes back from getUsage() and see what other methods you can call.  Hint, getUsage().toString() is a good place to start.

You may have seen be tweeting about Runnable.com this week.  I've spent a decent amount of time figuring out how their platform works and getting CFML (Railo) running on it.  Basically, Runnable.com is CFLive.net, trycf.com, and JSFiddle.net all mashed up and super cool.  In short, the platform lets developers post any code samples they want for any database/language/framework up on the Internet so other developers can come along and not only read their code, but run it right there in the browser.  It doesn't stop there, other developers and fiddle with the original code and run the new version right there on the site to figure out how it works.  

It's all possible with Docker.io, a cool virtualization platform I just learned about, and Runnable has the whole thing running on top of Amazons EC2.  Basically, each code sample is an entire Linux VM with whatever installed on it that the publisher wanted to set up.  The template of this VM is stored and every time a visitor comes to the site and wants to check out that code sample, a dedicated VM is spun up in seconds just for that user.  Docker.io allows them to simultaneously service hundreds of users because it shares overlapping resources between the VMs so they're very lightweight and come online in seconds.

And since each user gets their own isolated playground, there's no sandbox security to worry about.  In fact, each code page has an emulated bash shell with root privileges at the bottom of the page!  Any local changes made by the visitors of the site, are discarded after they close their browser and the session times out.  The code samples aren't limited to a single file of code-- publishers can create tutorials to demo entire frameworks, with multiple files. Need a database?  Install one.  Need Tomcat? Install it.

So, speaking of Tomcat-- this is where ColdFusion comes in.  Runnable's Twitter account popped into a recent conversation and urged us to get CFML setup, so i took the task and ran with it.  Due to some issue with the Railo installer which they're looking at, I installed Tomcat 7 with apt-get and deployed Railo 4.1 as a WAR file in the root context.  The Runnable guys were super helpful.  They exchanged several E-mails with me and even chatted on Skype for an hour last week answering questions, tweaking my setup, and writing down suggestions.  

I published a proof-of-concept Runnable called CFML Templating With Tags and then a more involved followup called Use WireBox To Create Objects In ColdBox.  I've also created a new GitHub organization called cf-runnable to store all my tutorials.  Feel free to send me pull requests, or ask to collaborate and store your CFML runnables there as well.  Now, what's really, REALLY cool about Runnable is anyone can clone one of my tutorials, make it their own, and re-publish it under their name.  That means no one else has to reinvent the wheel to start putting cool code up on Runnable-- I've already figured a lot of it out and you can springboard off of what I've done, or dive in fresh yourself.

So this is the intro to a blog series I'm going to do how how I got Runnable working with CFML, what little speedbumps I've hit, and how I've been integrating with GitHub to version and host my code.  I have a lot of ideas for Runnable- both improvements for them (like beefier descriptions, and embeddable runnables) and ColdBox-themed tutorials I want to create to let people play around with simple examples and how-to's.  Stay tuned!