1-1 beats N-M

SpiderMonkey, the JavaScript engine in Firefox, is moving towards a 1-1 threading model, away from a N-M model: JSRuntime is now officially single-threaded. Let me explain by looking back.

In Solaris the threading model is M-N, that is, for each program with N user threads there are M kernel threads servicing the program. This was thought to be the most flexible design and kernel threads were a limited resource.

Linux eventually settled on a 1-1 model, that is, for each program with N user threads there are N kernel threads each mapped uniquely to a user thread. This was found to be the simplest to code and the most performant in practice.

Back to JavaScript:

A single SpiderMonkey runtime (that is, instance of JSRuntime) — and all the objects, strings and contexts associated with it — may only be accessed by a single thread at any given time. However, a SpiderMonkey embedding may create multiple runtimes in the same process (each of which may be accessed by a different thread).

I read this to say: 1-1 mapping from SpiderMonkey to user thread. The same simplifications and performance gains Linux saw from the 1-1 model will be gained for SpiderMonkey.

Old lessons learned again; better than the alternative.

Spawn of Java

Brian McCallister writes Java Daemonization with posix_spawn(2), or as I like to think of it, Spawn of Java. The problem description:

The traditional way of daemonizing a process involves forking the process and daemonizing it from the current running state. This doesn’t work so well in Java because the JVM relies on several additional worker threads, and fork only keeps the thread calling fork. So, basically, you need to start a new JVM from scratch to create a child process.

The traditional way of launching a new program is to fork and exec the program you wish to start. Sadly, this also fails on Java because the calls to fork and exec are seperate, non-atomic (in the platonic sense, not the JMM sense) operations. There is no guarantee that the exec will be reached, or that the memory state of the JVM will even be sound when the exec is reached, because you could be in the middle of a garbage collection and pointers could be all over. In practice, this would happen exceptionally rarely, at least. Charles Nutter has talked about this problem in JRuby as well.

Visit Brian's post for the solution.

(You may also enjoy his related POSIX from Java post.)

Major code irritants

I could not agree more with this Java anti-pattern: Storing money in floating point variables.

In my interviews of Java candidates (or C++, for that matter) I always include questions about creating a hypothetical Money class, and pay close attention to their ideas for representation. International candidates often fare better on not assuming US dollars, but most all candidates fail completely on avoiding floating point.

Defaulting message fields in protobuf

Not well documented is the technique for defaulting message fields in protobuf. Say you have a field of message type, named "start" here:

message Complex {
    required int64 real = 1;
    optional int64 imaginary = 2 [default = 0];
}

message Vector {
    required Complex start = 1;
    required int64 length = 2;
}

How to you provide a default value, say at the origin? Like this:

import "google/protobuf/descriptor.proto";

extend google.protobuf.FieldOptions {
    // Pick the field number that is right for you!
    optional Complex complex = 50000;
}

message Vector {
    optional Complex start = 1
    [(complex) = { real: 0 imaginary: 0 }];
    required int64 length = 2;
}

See the Custom Options section for details.

Write your own kernel

James Malloy will show you how!

Better than null

A rich, delightful post from Joel Neely on an alternative to returning null to signal "not found" or "No": have the caller supply a callback with appropriate methods for condition signaling. In Java:

interface Found {
    void present(final String name);

    void absent(final String name);
}

class Phonebook {
    private final Set<String> names = new HashSet<>;

    void add(final String name) {
        names.add(name);
    }

    void remove(final String name) {
        names.remove(name);
    }

    void find(final String name, final Found found) {
        if (names.contains(name))
            found.present(name);
        else
            found.absent(name);
    }
}

class LookupPhone extends Phone implements Found {
    private final Phonebook phonebook;

    LookupPhone(final Phonebook phonebook) {
        this.phonebook = phonebook;
    }

    @Override
    public void present(final String name) {
        ringUp(name);
    }

    @Override
    public void absent(final String name) {
        complainIsUnknown(name);
    }

    void placeCall(final String name) {
        phonebook.find(name, this);
    }
}

(Keyed directly into the editor: apologies for typos.)

Bill Bejeck writes on Guava EventBus. This is very similar to the "MagicBus" code I wrote for a client while at ThoughtWorks in the mid-naughts. Essentially it is an in-process event bus respecting Java method signatures rather than a string-based topic space. You can write decoupled code in a pub-sub style within your own application.

In some weird sense it is an implementation of the COMEFROM instruction. When a "caller" publishes the right parameter list, subscribing methods are invoked as if called directly. Adding new subscribers changes the meaning of the call site. The difference is that control returns to the publisher after all subscribers run; COMEFROM is a complete transfer of control and does not multiplex.

Long live INTERCAL!