Erlang "processes" clarified

Now that I'm into erlang, I've been going through the Getting Started guide on the erlang.org site, and I found this little nugget:

the term "process" is usually used when the threads of execution share no data with each other and the term "thread" when they share data in some way. Threads of execution in Erlang share no data, that's why we call them processes.

I was always confused about erlang "processes" - if they were full-blown executable VM and OS-level processes or what have you. It's getting clearer now...

New Project - Erlang E-commerce

Well, now that we've moved to California (Sept 2008), and things are finally settling in, I'm looking for a new project to play with. At the end of long conversation with a current coworker, Steve Atkinson, about concurrency and the bear that it can be to wrestle with (especially in regards to shared state) I admitted that I'm interested in seeing how the new crop of functional programming languages deal with these types of issues.

So, to jump on a bandwagon (that's probably already left the station), I've decided to started exploring Erlang. What I want to do is create a small e-commerce style of application to see how the non-shared state model deals with the state of objects/entities like "customer", "order", and "product" over the lifetime of the application. I suspect my point of departure will look like a typical Java web-app (it's how I pay the rent), but am hoping to divert into something more or a true erlang app (whatever that may be). Further, since I have absolutely no background in functional languages, this should be a good learning and growing experience.

I'll try to jounal as much of the interesting details, thoughts, and ideas as I go along. However, we're expecting our second baby in about six weeks (holy cow!), so I'm not sure how much progress I'll make in the spring or summer. Either way, I'm hoping to gain another perspective on this whole programming thing...

Creating a Java annotation

So I created a new (method-level) annotation that basically just takes a string, and when the target method is invoked, via aspect I get that string. The annotation looks like this (name changed to protect the innocent):

public @interface Annotatable { String value(); }

After a few hours of banging my head, trying to figure out why everything compiled correctly, yet when testing I could never get the find the annotation on the target method. Turns out, this was soooo poorly documented by Sun/Java gods, you need to annotate your annotation, like this:

import java.lang.annotation.*;

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Inherited


The RetentionPolicy enum tells the compiler to keep the annotation around AFTER you compile, instead of throwing it away (like it does by default). The Target annotation tells the compiler which types of elements your annotation can apply to (classes, methods, params, all, etc.). The long and short of it is: don't forget to annotate your annotations.

NUMA and the JVM

Good blog entry from Jon Masamitsu about NUMA optimizations in Java 6 on Solaris. NUMA, essentially, and vastly simplified, is to access a region of memory that is physically closer to a processer on a multi-processor system. This way there's less latency when reading/writing to the general memory region. For Java, the optimizations are made primarily to the Eden (young generation) heap space, as well as assigning a thread to a particular CPU.

To enable the feature. it's a command-line param to the JVM at startup: -XX:+UseNUMA .

Java 6 threading article

An article on Java 6 threading optimizations recently appeared on infoq. It's a good article in two parts, but here I'm just going to capture some of the interesting notes about the different locking features now in the JVM (most of this entry is paraphrase - that is, notes to myself).

Escape analysis - determine the scope of all references in an app. If HotSpot can determine the refs are limited to local scope and none can esacpe, it can have the JIT apply runtime optimizations.

Lock elision - when refs to a lock are limited to local scope (for example creating an modifying a StringBuffer), no other thread will ever have access to object; hence it is never contended for. Then, you really don't need the lock anyway and can be elided/omitted.

Biased Locking - most locks are never accessed by more than one thread, and even when multiple threads do share data, access is rarely contended. Long story short, this makes subsequent lock acquisitions less expensive by holding onto lock until somebody else wants it. Java 6 does this by default now.

Lock Coarsening (or merging) - occurs when adjacent synchronized blocks may be merged into one (if same lock is used for all methods). For example. when calling a series StringBuffer append() operations. Locks are not coarsened inside of a loop because the lock will be held for (potentially) too long.

Thread suspending versus spinning - When a thread waits for a lock, it is usually suspended by the OS. This involved taking it off the stack, rescheduling, etc. However, most locks are held for very brief time periods (based on profiling), so if the second just waits a little bit without being suspended, it can probably acquire the lock it wants. To wait it just goes into a busy loop - known as spin locking. Was introduced in Java 1.4.2 with a default (fixed) spin of 10 iterations before suspending the thread.

Adaptive Spinning - Spin duration not fixed anymore, but policy based on previous spin attempts on same lock and state of lock owner. If spinning likely to succeed, will go for a longer iterations count (say, 100); else, will bail on spinning altogether and suspend.
Introduced in Java 6.

devWorks Benchmarking article

This is a great article from the IBM devWorks site about Java performance benchmarking. I'm just capturing some notes in this entry.

Measuring time:

1. System.currentTimeMillis() - gets the "wall clock" time, but the updates from the OS are hardware dependent and may only occur every ~10 ms. call to OS returns instantly
   
2. System.nanoTime() - returns a differential time, measured in microseconds, bu the call to the OS itself can take microseconds.
3. ThreadMXBean - JMX extension that offers to read a Thread's CPU usage (may be misleading due to I/O and it's uage may be expensive)

Code warmup:

• Class loading can be observed via ClassLoadingMXBean
• Most VMs run the code for while in interpreted mode to gether stats before performing JIT compilation. Sun's Hot Spot defaults: 1500 time for client VMs, 10,000 for server. Could use CompilationMXBean to measure JIT time, but impl is hosed. Alternative is to watch stdout with -XX:+PrintCompilation JVM option
  

Grails + email service

Alright, finally getting back into to grails coding after a long time away. For my test pet store application, I decided to take a day and create newsletter sender. Basically, it just takes an email address (submitted via a little form widget thingy), and stores it in a separate table the database. I'm not bothering with user accounts yet for the site, so I'm just keeping it in a stupidly simple table with just a database id and the address itself. There's also a controller function for removing an address from the list (handy I should think).

Now that I've got email addresses to send to, I need to actually send the newsletters. Before tackling that, though, I want to send out the newsletters on a periodic basis, so i need a scheduling/cron like component. I decided to use the Quartz plugin for Grails. We use it at my $DAYJOB, and it's been an excellent workhorse there. After installing the plugin (grails install-plugin quartz), and creating a job (app-home/grails-app/job/SendNewletterJob.groovy), I was 80% done. I just had to define my scheduling and implement the execute() method, which calls my message send service. Easy! Here's my source:

class SendNewsletterJob {
def timeout = 9000l //runs every nine seconds (only for testing!)
def emailService

def execute() {
emailService.sendNewsletter()
}
}

Now for actually pushing the newsletter to the users. I created an app-home/grails-app/services/EmailService.groovy. In Grails parlance, from what I understand, a "service" is not a web-service (REST or SOAP), per se, but more like the Eric Evans DomainDrivenDesign notion of a service. Currently (May 2008) there is no nice plugin for sending email, but there is a nice document on the Grails site that describes how to create a mechinism that wraps Spring mail. I just ripped off the example EmailService, dropped my smtp host values into my grails-app/conf/spring/resources.xml, and I'm business.

Altogether, this project took less than four hours, most of which was fishing around playing with config settings and such. I'm trying to think what the parallel time investment would have been for a straight-up Java implementation. Hmmmmm.........

Pat Helland speech

Wow - another reason why Pat is truly one of my heros: Speech from 2007 TechEd EMEA