mult.ifario.us

Another entry for my personal Devil's Dictionary:

kickboxing, n. A programming language idiom whereby a kick is converted to a Kick.

The kid is a teething machine, by which I mean that she has quite a few teeth for a sixteen-month-old, and she's getting more with her top and bottom canines on their way in and then only her four back molars left. Combine this with a normal amount of toddler testiness, and you've got a recipe for some pretty good outbursts. This past weekend, we were having lunch, and her mood came to a head. She picked up her plate with clear intent to throw it, but I caught her in mid wind-up. Her response to a stern "No." was a seething look of anger that turned her whole face bright red.

After she was cleaned up and running around, my wife commented, "It's good that she doesn't have pyrokinetic powers, or she'd have burned you into a little potato chip." Nonetheless, I'll be on the lookout when she hits puberty...

It looks like SUN's serious about open sourcing Java, where Java means the JDK. Among the various languages that I use, I could count the number of times that I've looked at the source code for Ruby, Python, Perl, GCC, GCL, and GHC on the fingers of an absent-minded stonemason, and almost all of those times have been when I wanted to compile something bleeding edge on an obscure operating system. Diving into a highly complex codebase and making positive changes simply isn't done. The SUN JVMs are already open enough for my taste. The JVMTI is available as a plug-in point, and the source code for the Java standard libraries is available.

Will "open source Java" prevent cruft from getting into the standard libraries for Java or evict some of the current dross and detritus? Will it save us from the next EJB or Crimson? Strip the Java standard libraries down to a minimal subset of what they currently contain, don't put it back, provide a great package manager, and that's open enough for me.

If Yogi Berra managed software projects, he would say things like what I heard on a conference call today:

Are there any risks you're not aware of that could impact the "go-to-staging" date?

The subject of when to use the throws declaration on a method definition in Java came up in a discussion recently, and my personal preference can be expressed in one simple rule:

An exception belongs in the throws declaration if and only if it is actually thrown in the body of the method.

In fact, it's so simple that it can be expressed in PMD 's XPath syntax:

//MethodDeclaration/NameList/Name[\
@Image != ../../Block//ThrowStatement//\
AllocationExpression/ClassOrInterfaceType/@Image]

(The backslashes are linebreaks and not part of the actual expression.) The expression might look a little odd, but it works because a string (a member of the throws declaration) and a nodeset (all of the throw new Foo in the method body) are equal according to XPath 1.0 if the nodeset contains a node with the same string value as the string.

Kids absorb and imitate. Two recent events reminded me about just how well they absorb and how strong the desire to imitate can be.

Television is the lead plumbing of our age, and we give the kid only small doses. She'll get more than enough of it through friends and relatives anyway. Only PBS/Sprout, only shows with slow-paced visuals. She's seen a couple episodes of Sesame Street, at most. Nonetheless, she knows who Elmo is. A couple of weeks ago at Freddy's, she selected an Elmo-branded baby toothbrush for herself. It went back on the rack; we bought her an unbranded one. Then, at Whole Foods, she spontaneously snagged some Elmo-branded oatmeal off the shelf. That went back on the shelf, too, since oats have never been her favorite, and I'd rather give her the good stuff.

We took the kid out to a reasonably nice restaurant recently, ordered escargot as an appetizer and gave her a few slices to try. Since she was about six months old and would lunge for food on the table, she's wanted to at least try anything that we're eating, and usually she likes it. We manage to keep the things from her that she shouldn't have (unpasteurized cheeses, less than fully cooked eggs, etc.), but once she catches you eating something, she wants to try it. It's very likely that she'll remember the appearance or packaging and try to sneak up to the table, climb onto a chair, and snag some while the table is being set. She has also started insisting on having the same utensils that we have for a meal. This doesn't work out well for chopsticks, but it works OK for forks. Her version of using a fork is to spear something with the fork and then take it off with her hand and pop it in her mouth. (She does does know how to use a fork properly.)

For anyone who's been wondering why this blog has been up and down over the past week, it's a slow-motion battle between the memory police at TextDrive killing Typo instance that hosts the blog and either a FastCGI dispatcher or a nanny cron job starting it back up. The onus is clearly on me to figure out what's burning memory, and my first inclination was to naively google for Ruby profilers. Here's a rambling account of what I did to conclude that I'm probably out of luck as far as a quick cure for the issues and then to address them.

There are a couple of speed-oriented Ruby performance profilers, the built-in one and ruby-prof, but there are no space-oriented profilers. There was a brute-force approach based on ObjectSpace.each_object in an old mailing list post from Michael Garniss that looked suitable, so I integrated it into the main controller in Typo as an after_filter and fired-up several concurrent wget commands to walk around on a production configuration on my development box at home:

while true; \
do wget -nv -r --delete-after http://localhost:3000; \
done

(There is no reason to try to set it on fire with something like ab.) That won't catch any issues with the vanilla two dispatcher lighttpd/FastCGI configuration that I use on Textdrive, but it should catch any issues with Typo internals, badly behaved sidebars, etc.

With the profiling code integrated, a request that includes the dump takes several seconds to complete, and there are several hits per page; so I added a class variable (@@no_sooner_than) and a little logic so that profiling requests would only run once a minute or so. With several wget walkers working, top reports that the server runs along at a happy 80-90Mb, and eyeballing the profiling output shows memory usage oscillating between <7Mb and ~20Mb without any perceptible upward trend over the course of an hour and a half. (That said, that's all the data I captured, as WEBrick locked up completely after that hour and a half.)

Armed with the information that there wasn't an easy fix for the memory issues, I switched the FastGCI configuration for the production instance to a single dispatcher from the previous two, pointed a couple of wget walkers at it, and tracked memory usage and process id at the commandline, like so:

while true; \
do ps mux | grep ruby | grep -v grep; \
read -t 30; done

I also changed the wget walker command to provide more useful information:

wget -S -r -b -l 4 --delete-after http://mult.ifario.us \
-a /tmp/log_id

where id is a unique number per walker, and so far, so good. Crunching the wget output through shell commands (awk, grep, cut, sort, uniq -c, etc.), e.g.:

cat log* | grep HTTP/1.1 | cut -f 4 -d ' ' | sort | uniq -c

says that mult.ifario.us is consistently returning snappy HTTP/1.1 200 responses about two nines (99.x%) of the time, which isn't great but isn't awful. (Really it's more like 2.5 nines, i.e., −log₁₀(0.003), but who's counting?)

This is one time when I've missed some of the Java runtime environment's capabilities (i.e., the JVMTI) in other language runtimes, but no rocket science was required to get Typo under control.