RealityForge.org

Antix - and tasks for Ant

2011-08-07T00:00:00+10:00

A long time ago I was involved with the Ant project and part of the philosophy was that Ant was not executable xml. So this meant that <if/> and <for/> tasks were out. Implementing the equivalent functionality involved complex sets of tasks and properties to be defined.

Fast-forward many years and Ant still does not provide this functionality out of the box. I rarely use ant these days opting instead to use Buildr or Rake depending on the project. But when I do use Ant I find myself re-implementing the same set of tasks - usually <if/> and <forEach/>. A while ago I consolidated all the different implementations under one source tree, Antix on Github.

Someone asked me how to use them so here is a basic description...

Setup

The simplest way to install Antix is to download the jar and add a taskdef to your build file.

Jar: http://cloud.github.com/downloads/realityforge/antix/antix-1.0.0.jar

<taskdef resource="org/realityforge/antix/antlib.xml">
  <classpath path="path/to/antix-1.0.0.jar"/>
  <!--
  This task library can also be put in the
  ${ANT_HOME\}/lib directory, in such case this
  classpath node is not needed
  -->
</taskdef>

Benefits

The <if/> task

The <if/> is simple in that it has two child elements; conditions and sequential. The sequential has a a sequential list of tasks to execute if all of the conditions evaluate to true.

e.g.

<if>
  <conditions>
    <equals arg1="${my.build.parameter}" arg2="true"/>
  </conditions>
  <sequential>
    <echo message="The property my.build.parameter is set to true!"/>
  </sequential>
</if>

The <forEach/> task

The <forEach/> takes a list of white space separated values and invokes a nested sequential element for each value, setting a specific parameter to the value during the invocation.

e.g.

<forEach property="day" list="Mon Tue Wed Thu Fri">
  <sequential>
    <echo message="Day = @{day}"/>
  </sequential>
</forEach>

will print ..

[echo] Day = Mon
[echo] Day = Tue
[echo] Day = Wed
[echo] Day = Thu
[echo] Day = Fri

The <property-copy/> task

Ant properties are not allowed to be nested so you need to do some hackery to get get nested properties to work properly. The Antix library implements the approach recommended by the FAQ by implementing a property-copy task that will evaluate the property two layers deep and copy the value to another property.

This is typically used when you are selecting from a variety of different build configuration settings. i.e. Should you generate the EJB or web service generator.

e.g.

<property name="ejb.service.generator"
          value="com.biz.EjbGen"/>
<property name="ws.service.generator"
          value="com.biz.WebServiceGen"/>

<property name="generator-type" value="ws"/>
<property-copy name="service.generator"
               from="${generator-type}.service.generator"/>
<echo>service.generator=${service.generator}</echo>

will print ..

[echo] service.generator=com.biz.WebServiceGen

The <dbgmsg/> task

The dbgmsg task will only print the specified message if the property named "debug" is set to a value. This is mostly used when debugging builds.

<dbgmsg message="My debug message"/>

The <start-phase/> and <end-phase/> tasks

The start-phase and end-phase tasks are used to print the time it takes for various build phases. Each phase has a name and a timer starts when start-phase is executed and is stopped when end-phase executes. Both tasks echo a message at warning level (if the property named timing.check is set) or at the verbose level.

e.g.

<start-phase phase="integration-tests"/>
...
<end-phase phase="integration-tests"/>

will print ..

[echo] Starting phase 'integration-tests' at 18:15:39
...
[echo] Completing phase 'integration-tests' at 18:15:39 (Duration = 48ms)

The <toAscii/> task

Copy a file while replacing non-ascii characters with the character '?'.

e.g.

<toAscii src="SomeNonAsciiFile.txt" dest="SomeAsciiFile.txt"/>

The <selectRegex/> task

The selectRegex task attempts to extract a value from a string based on a regular expression and assign that value to a property. Often I use this to extract out results from tests to do further processing.

<selectRegex property="that"
             pattern="string (.*) will"
             select="\1"
             value="My string that will attempt to be matched."/>
<echo>that=${that}</echo>

will print ..

[echo] that=that

The <timer/> task

The timer task can either be a "start" or "stop" timer. A "start" timer sets a property to now indicating a start time. A "stop" timer sets a property to now that indicates an end time and it calculates the duration from the corresponding start time. Mostly this task is not not directly used but instead used by the start-phase and stop-phase tasks described above.

<timer property="mytimer" stop="false"/>
<echo>Start: ${mytimer.start}</echo>
<timer property="mytimer" stop="true"/>
<echo>Stop: ${mytimer.end}</echo>
<echo>Duration: ${mytimer.duration}</echo>

will print ..

[echo] Start: 1312706159383
[echo] Stop: 1312706159397
[echo] Duration: 14

GWT and EJB 3.1

2011-08-06T00:00:00+10:00

Recently we have been tasked with building a rich, complex web application for resource planning. Historically most of our applications have been successfully delivered using Rails. However the cost of developing rich applications has been significant and only a few developers are comfortable working with low-level javascript frameworks.

We prototyped the front-end using ExtJS and were looking at implementing the backend technology using EJB 3.1 beans (See Why EJB? for our reasoning). We investigated using JSF and GWT as the front end technology but eventually settled on GWT, took a course and went through a number of labs to develop a simple GWT application.

The course only gave us a taste of GWT and we still needed to do a bunch of investigation to get a GWT application from "toy" stage to production ready. We took the best practices MVP example and started to evolve it towards an archetypal example in our world. This involved adding an automated build system that we could run from our CI box, moving to EJBs for the service layer, JPA for the persistence layer, moving to Intellij IDEA for the IDE and splitting the project out into multiple components that could be worked on independently.

The code for converting the service layer to EJBs was actually quite simple as is evidenced by the commit. However this code does not work in the built-in Jetty container used as part of development mode. The documentation on how to actually use EJBs is rather thin. In Intellij IDEA, this entailed setting up the IDE to build an exploded war, configuring GlassFish support and passing -noserver to the GWT plugin.

For the build system we initially trialled using Maven 3.0.3 but went back to using Apache Buildr. Maven is a project I want to like and has great ideas but even years after it was developed I keep running into stability issues; plugins don't work, dependencies are not locked by default etc. Buildr is a little rough around the edges but does not get in your way when you want to do something custom. The commit that converted the project to buildr is a perfect example. There is very little code involved in the Buildr files buildfile and build.yaml but there is a fair amount of custom code involved in modifying the Intellij IDEA buildr extension so that it generates custom metadata for the build. Admittedly these customizations will be rolled back into Buildr over time but it was simple to extend core Buildr classes to achieve our immediate needs.

Separating the different elements of the application out into separate components proved to be a minor annoyance. The code remained unchanged but the build system had to be refactored significantly as did the Buildr customizations to generate the IDEA project files. However, you can see a snapshot of the current work in progress on github project at the tag BLOG_POST.

Footnotes

Why EJB?

We need to integrate with a thick Swing client over a custom network protocol and a web portal & BPMS using SOAP web services as well as the front-end for our new application. Candidate service layers included OSGi, Spring and EJB 3.1. Bizarrely enough we chose EJBs because it was simpler (!!!) to provide these interfaces in the straight JEE stack. (And yes we were very surprised to come to that conclusion too!).

GWT Course

The course was delivered by Adam Jenkins at Object Training and it was quite good. About the only complaint I have was that some of the architectural labs and talks were too focused on mechanical aspects and did not make the reasons for selecting a particular architecture clear. I came away thinking that the GWT MVP design pattern was developed by architecture astronauts but after reading more and watching a few YouTube clips I am sold on the approach.

Meta-Data is an overhead

2011-06-06T00:00:00+10:00

‘Portrait of a n00b’ raises the issue of meta—data addiction and puts forth the proposition that way too many programmers are afflicted by this condition. Every time a programmer is forced to annotate their code or “computation”, this increases the cost of maintenance, evolution and change as the meta-data must be kept up to date. Sometimes the meta-data can provide some useful information (i.e. documenting the intention of code) that offsets the cost of the meta-data but this is often not the case.

A small child who is describing what they what they have done will often provide a list of minutiae inter—spiced with “… and then I …”. The sentence structure is often simple and repetitive. Often the child will explicitly explain what they mean when they encounter a subject that they feel is complex. As the language skills develop the person will be able to focus on more salient features and use more sophisticated language. The information density of the speech act increases and many subtle nuances can be combined in one speech act.

This parallels the development of a programmer. The more sophisticated the programmer the more compressed their “speech acts” aka programs will be. They start focusing on more salient features of the program and start using more sophisticated techniques (i.e. higher-order programming). The information density dramatically increases as the programmer develops.

This has an interesting implication for some common approaches used within development process. Often adept programmers are forced to program in such a way that less adept programmers can understand. Worse yet they are forced to program in a consistent style with far less adept programmers. When the skill discrepancy is large this can effectively dilute the effectiveness of the more skilled participant. It is like forcing Shakespeare to tell his stories in baby talk: the story will inevitably loose many of the nuances and expand to massive size ¹.

Comments are one form of meta-data that is common in programming. A “young” developer often writes many comments describing every step of the code. The comments can be in-band comments (i.e. javadoc and other code comments) or out-of-band comments (i.e. UML diagrams and sequence diagrams). As the developer becomes more sophisticated, the comments are often compressed and restricted to more complex aspects (i.e. more salient). The more mature developers seem to take the approach that the code is the document and attempt to restrict the code to high level descriptions or essential complexities that can not be removed.

Of course this not apply to all programmers. As in natural language there is all sorts of reasons for using language. The above description applies to those programmers working in a small team of similarly skilled individuals who have the aim of producing a product with a balance of flexibility and robustness. Programmers who were working in a larger team have to worry about potential miscommunications and thus need to be far more precise in their communication (even if all members of the team are of roughly equal skill).

Comments as meta-data require some maintenance to keep correct. Incorrect documentation is often far worse than no documentation at all as it creates some confusion in the reader. Is the code wrong or the comments wrong? Have I misread the code or the comments and is it thus me that is wrong? The cognitive dissonance can be extremely disruptive to action².

Psychology experiments that ask a person to read a color word show that if the word is written in the same color the reaction time is fastest. The next fastest is when the word is written in a neutral color (such as black). The slowest reaction time occurs when the word is written in a non-neutral color that is different from what the word says (i.e. the word “red” written in green ink). With my pop-psychology sun glasses on I would hazard to guess that a similar impact is at work when meta-data does not line up.

So the value of meta-data is often relative to the level of compression of the meta-data (is it about a salient feature or does it “trivially” follow from the code (where trivial is relative to the programmer skill level), the chance that meta-data could be out of date (i.e. is it verified by a compiler or checker of sorts), the cost of maintaining the meta-data and the chance that the code and thus meta-data is likely to change.

The distinction between meta-data and data is often an arbitrary point. If meta-data is verified then is it really meta-data or is it just more data? Are the types within a statically typed language really data or meta-data that the compiler checks?

The claim that static types may in fact be frivolous meta-data that people can do with out raised a number of hackles as is to be expected. The most interesting counter – ‘Concretizing static typing metadata’ made the claim that the static typing that “concretizes” the meta-data was not just for error avoidance but also aimed at actively increasing programmer productivity.

One of the more interesting points made in ‘Portrait of a n00b’ is that the failure of the semantic web is largely due to the fact the people will NOT spend considerable resources adding meta-data to their data. Systems with extreme levels of typing tend to also fail to gain traction outside of academia (where it offers many “research” opportunities in the same sense philosophy does) and defence / aerospace industries (and the adoption of ada may actually not be due to preference or any expectation by the individuals that it will bring better reliability but instead be due to a mandate from on high that were influenced by academic partners).

¹ It should be noted that Shakespeare often wrote for the common person and thus far less sophisticated people could understand and appreciate the work even if they missed the subtle nuances. However programming often has more in common with multiple people writing a story or perhaps multiple people creating a film. Having to talk to some of the people in baby talk is going to slow down the operation.

² When the code and comments line up and people expect them to line up then action may be faster but more action is required when the code needs to be altered thus potentially drying up any wins gained from faster action.

Babel

2011-06-05T00:00:00+10:00

Ba⋅bel /ˈbeɪbəl, ˈbæbəl/ (noun)

an ancient city in the land of Shinar in which the building of a tower (Tower of Babel) intended to reach heaven was begun and the confusion of the language of the people took place. Gen. 11:4–9.
(usually lowercase) a confused mixture of sounds or voices.
(usually lowercase) a scene of noise and confusion.

Source

Babel is a proposal for a multi-paradigm, low level type-safe virtual machine capable of executing several different programming languages. Different programming languages will inevitably be optimized to solve certain classes of problem in certain domains. No single programming language or programming paradigm is ideal in all scenarios.

The aim is to be able to execute virtual instruction sets from several different virtual machines such as Ruby/rubinius, Java/Java bytecode, Erlang/Beam, Scheme, Haskell, Mercury, R etc. Different types of languages that are expected to be supported should represent functional, logic or constraint-based, message-based and imperative paradigms.

In an ideal environment it would be possible to transparently combine elements written using different paradigms in the same application. The impedance mismatch at the language barriers often makes this a difficult proposition.

One possible remedy is to host each different programming language or paradigm in a software isolated process (SIP). Each SIP communicates with other SIPs through message passing. Communication between SIPs would still need to translate values from one paradigm to another and may even need to serialize, deserialize or copy values between SIPs. However translation could be skipped when processes share a representation and in some scenarios copying may be avoided if a SIP supports copy-on-write or can only transfer immutable values.

SIPs have many of the advantages of Erlangs processes; fault isolation, low overhead, easy to parallelize. If Babel is structured correctly, the exection engine for each SIP could be shared between SIPs and maybe composed from elements such that a logic and functional SIP share many of the same VM components.

Babel is unlikely to be started until well after I complete my PhD and while I have experimented with several different components at times, no head way has been made. For Babel to have any chance of success it must be optimized for fun.

Instruction Set Composition

It is likely that the various programming languages that are built on the Babble VM (BVM) can share subsets of their instruction sets. Candidate instructions that immediately come to mind include arithmetic operations for 32-bit integer values and 32-bit IEEE 754 floating point values. It is also likely that there will be dependency relationships be instruction groups. i.e. The 32-bit integer vector operations rely on the presence of 32-bit integer scalar operations.

Each instruction group is likely to result in different sets of optimization passes being incorporated in the runtime compilers. These could be a new set of BURS rules or specific optimization passes (i.e. to vectorize scalar operations in loops). Thus each instruction group should be able to be bundled separately and identify associated optimization passes etc.

Layered Programming Language Features

The BVM is likely to have a family of “native” languages. The languages should be layered such that each successive language incorporates features from lower layer. The “kernel” language is most likely going to be a stack based language such as Joy/Forth with linear types and procedures/functions that are guaranteed not to be recursive. The next higher language may support recursive functions and immutable variables (i.e. those that can be written once and read many times). A higher layer still may support mutation of variables or polymorphic invocations.

Language features such as generic types, tail calls, lazy vs strict modes, query matching vs normal execution, object manipulation etc are gradually added depending on where the language is positioned in the kernel-system-application-scripting language spectrum. Ideas should definitely be incorporated from Forth, Scheme, Haskell, Smalltalk and Mercury when developing the composable language features.

No Scope in Computer Science Research

2011-06-03T00:00:00+10:00

Computer Science research seems to be tackling all the wrong problems. Rather than fixing the source we attack the symptoms and we do so with such a rigour that the irrelevance of the solution is often forgotten. Research that attempts to address the source of problems is often considered too broad, too academic or ignoring commercial realities. What is worse is that research that tackles the symptoms is often well funded but completely irrelevant by the time it makes any progress as a change in the underlying computing infrastructure has shifted the symptoms to a different location.

Automatic Memory Management

Very few people will argue that automatic memory management (AutoMM) is not a vast improvement over manual memory management (ManMM) for most problem sets. In some scenarios AutoMM will have better performance than even highly tuned ManMM but in most cases the simplicity bought using AutoMM has a space or time performance cost.

Most research into AutoMM or garbage collection (GC) as it is more commonly called, focuses on the analysis of memory usage patterns of existing applications in existing runtime environments and adapting or tuning existing approaches. As new languages and problem domains become popular regularly there will always be new tweaks possible. Thus this approach can provide a steady stream of research papers but it is hardly ground breaking stuff.

A more interesting approach to AutoMM research would be to tackle the bigger problems. Rather than reacting to changes, proactively propose future changes to the programming practices to improve GC. I suspect that most existing AutoMM would be inadequate in the face of 1 TiB or 1 PiB of shared memory. If the performance gap between processor speed and memory access latency keeps widening how will this effect GC algorithms? As the number of processors increases in systems, how will this effect GC? Essentially we need to find what changes need to be put in place so that future generations of hardware and software platforms are more amenable to AutoMM.

My understanding is that most GC algorithms will partition the available space into logically separated spaces. Allocations that share common characteristics (e.g. traceability, size, lifetime and locality of reference) will be placed in a common space. A space can be collected if no other space references allocations within the space or the referees can be patched or the spaces of the referees can be simultaneously collected.

Most GC algorithms aimed at SMP systems, have a worst-case scenario that will cause all spaces to be simultaneously collected. This is obviously going to have some serious performance repercussions. To combat this, some approaches will separate the tracing into one phase and incrementally collect/move the allocations over a period of time to reduce the spike in response time. (I am not sure what the correct term is under GC but by response time I mean the time between when an allocation starts and when it completes.) The tracing phase will still take too long if there is a large number of references or the references are not “cache-friendly”. The memory hierarchy of most hardware is designed to work well with locality of reference but most (all?) tracing is not going to have that characteristic¹.

AutoMM research into a 1 PiB shared memory system may not have been addressed in current PL but most probably have been examined within distributed file systems or distributed garbage collection. Solving these problems is almost certainly going to require changes in the programming environment and GC algorithms. Maintaining locality of reference is also likely to have consequences in performance and programming style.

Machines and Instruction Sets

Now consider the boundary between hardware and compilers; the instruction set architecture (ISA). For all the massive advances in computer architecture we seemed to have been hobbled ourselves with bad ISAs designed for historically interesting domains that no longer exist (The exception seems to be GPUs which are unconstrained by historical choices and typically have drivers that compile from a byte-code to their own instruction set). IA-32 (and IA-32e) show their lineage from a time when people wrote programs in assembly directly and the time where memory access was slow compared to computation. But IA-32 seems to be quite difficult to generate efficient code for (especially as the rules keep changing).

bq. Just as an aside, to give you an interesting benchmark—on roughly the same system, roughly optimized the same way, a benchmark from 1979 at Xerox PARC runs only 50 times faster today. Moore’s law has given us somewhere between 40,000 and 60,000 times improvement in that time. So there’s approximately a factor of 1,000 in efficiency that has been lost by bad CPU architectures. ²

CoGenT is one of the more interesting projects relating to this area. In this scenario they model each ISA instruction as having an internal representation (i.e. the bits), an external representation (i.e. assembly) and a semantic interpretation. The hardware such as instruction pipeline, memory hierarchy etc are also modelled abstractly and in theory you can combine the hardware description and ISA description to create a simulator. However – a more interesting proposition is creating the back end of a compiler automagically. You see a compiler essentially represents the code as a semantic tree and CoGenT tries to automagically create a transformer³ from the compiler semantic tree to the machine semantic tree taking into account machine characteristics and thus predicted performance characteristics⁴. I suspect transforming one tree representation to another while minimizing the cost is one of those NP problems but this does not mean it is a hard NP problem or that a reasonable approximation will not do. (It should be noted that most register allocators are just another tree transformation from abstract registers to real registers that is driven by cost analysis and semantics of registers.)

Interestingly enough the tree transformation approach has been baked into certain programming languages from early on (i.e. the Lisps). The scheme macros (i.e. hygienic) base the transformation on syntax and are not directed by cost analysis but could provide an interesting view. UNCOL demonstrated there is unlikely to be any universal IR but it may be possible to create a universal tree manipulation language. An interesting hardware platform might be to focus on would be one where there is 1000s of cores on a chip⁵.

¹ I am not aware of any hierarchical GC schemes that explicitly take into account the memory hierarchy or adjust the algorithm based on memory access speeds. Increasing the locality of reference either by changing the GC algorithm, the programming environment or style would likely give a significant performance boost.

² Alan Kay. A conversation with alan kay. In ACM Queue, volume 2. ACM, December/January 2004-2005.

³ I think from memory it actually outputs a bunch of BURS-like rules which is effectively the same thing.

⁴ Now transforming one tree to another based on cost analysis … hmm does this not sound like what most compiler optimization phases do?

⁵ Krste Asanovic, Ras Bodik, Bryan Christopher Catanzaro, Joseph James Gebis, Parry Husbands, Kurt Keutzer, David A. Patterson, William Lester Plishker, John Shalf, Samuel Webb Williams, and Katherine A. Yelick. The landscape of parallel computing research: A view from berkeley. Technical Report UCB/EECS-2006-183, EECS Department, University of California, Berkeley, Dec 2006.

Type Dictionary

2011-06-02T00:00:00+10:00

Imagine a programming environment where the type implementations need not be bound to a name or may be bound to multiple names. Type implementations just consist of a collections of methods and fields. A type is only associated with a name when it is registered in a directory service. The type need not be registered or it could be registered under multiple names depending on the whims of the programmer. So far this could be a description of any number of type systems for dynamic languages such as Ruby.

A type that refers to another type would use a particular resolution protocol to determine the type of the referred entity. Consider a type that declares that it is derived from the type “MyParentClass”; the simplest resolution protocol may state that it looks in the directory for that name in the current context. Another resolution protocol may state that it looks for the name within the context of the declaring class and then it each parent context until the name is found. So if the declaring class name is “MyClass” and it is in the context of “/mygroup/myapp” (i.e. it is bound to “/mygroup/myapp/MyClass”) then it may first look for the class in “/mygroup/myapp/MyParentClass”, then “/mygroup/MyParentClass” and finally “/MyParentClass” stopping if it finds the type. This resolution protocol is not dissimilar to the default resolution protocol used in the JVM where each context is a classloader and the name is the classname. The difference is that in the JVM each context can override the default behaviour and implement a custom resolution protocol and the contexts are just objects that need not be registered anywhere.

Using the directory as the central location to bind names to types has some interesting implications depending on the characteristics of the directory and the types. Can types be rebound? Or can names only be bound once? Are types that are candidates for garbage collection automagically unbound? Can an unregistered type be used to instantiate instances of objects or must it all be routed through the directory? Are contexts symbolically named or to they effectively use a PID. Are context PIDs accessible outside the context and are they forgeable? What are the rules for types in one context referring to types in another context? Is it disallowed or can only parent contexts be referred to? Do references from context A to context B restrict the ability of B to be garbage collected or does the collection of B force A to fault?

We could also go one step further and consider types to be just another “context”. Each instance of the type effectively has a local directory context that is examined when invoking a method, accessing a field or sending a message. So binding a type into the directory is effectively just binding a different kind of context into the directory.

So the directory consists of:

Names bound to a context that contain a collection of classes (a.k.a. packages or modules).
Names bound to a context that contain a collection of fields and operations (i.e. The Class).
Names bound to methods and names bound to fields. Private, protected and public access specifiers are mechanisms that change the resolution policy for fields.

This seems to indicate that functions and potentially fields should be first class objects that can be passed around. Creating a type is effectively binding functions or fields together and potentially also adding in binding parameters. A binding parameter determines whether a inherited type can rebind the name or access the bound value.

An interesting thought exercise. Maybe I will see how it plays out next time I feel the urge to write another interpreter.

Making Whitespace Significant

2011-06-02T00:00:00+10:00

Every time I code up a new programming language I forget one of the most important things about programming languages. High level program languages should be designed to make it easy for humans to read and write rather than trying to make it easy for computers to parse or execute.

Whitespace and indentation in particular, is significant to humans when representing logical structure but rarely does the programming language consider indentation as significant (Python and Haskell are exceptions to this generalization and the logical structure of a program is represented by indentation level.). Most program languages use explicit tokens such as begin and end or { and } to mark the start and end of logical blocks. In these languages programmers tend to use both indentation and the explicit block delimiters, thus introducing redundant information that may become out of sync. A poorly indented program can be much more difficult to understand. By “poorly” indented I mean that the indentation does not represent the logical structure of the program or worse – gives a false impression of the program structure.

The article [In praise of mandatory indentation for novice programmers], seemed shocked that a language that uses indentation to delimit blocks was such a boon to novice programmers. Most of the objections that arise when proposing indentation as significant are not applicable to novice programmers. They have not yet learnt enough to think it is weird and in fact it may be more familiar as that is the way they are taught to structure their natural language writing. Nor do they have any stylistic idioms that they have developed over years and rigidly adhere to. Novice programmers have not yet to learnt to chunk code at a higher level and thus increasing the number of tokens tends to increase the number of chunks they have to remember (potentially exceeding the 7+/-2 rule).

Style is another issue that seems to crop up with high frequency. Countless hours have been wasted debating the tiniest and most irrelevant details of laying out of code. Do spaces occur outside or inside braces? Does the { appear on a new line or not? Do you use tabs or 2/4/8 spaces to indent code? For any significant codebase using a single style is going be a benefit but no style is likely to have any significantly greater benefit than any other commonly accepted style. Yet we waste time debating style, writing tools to reformat code and writing tools to check code compliance.

To deal with this, [Style is substance] proposes that for each language a definitive style is selected and enforced by the grammar. More than just using indentation to indicate program structure this locks down every style variation so that there is just one style. No longer would we need separate tools to enforce style (it would be done by the compiler) or format code and nor would there be a gazillion options in IDEs to determine how the code lay out.

Selecting one style and enforcing it is an embodiment of Python’s philosophy “there should be one obvious way to do it”. Under the python model the language implementer selects the “one way” and those who use the language must put up with it. Compare this to Perl’s philosophy “there is more than one way to do it” (TIMTOWTDI). This philosophy encourages each person to adopt their own style and often fellow Perl programmers have difficulty reading each others code where as most Python code is easy to understand to a fellow Python enthusiast. The problem with the Python approach is that sometimes the language implementer gets it wrong and it is not possible for the users to route around the problem.

Ruby does not attempt to dictate a single approach but it does not fervently adhere to TIMTOWTDI as does Perl. If people have a problem with ruby they are given enough power to fix the problem. If the “fix” attracts the attention of the language implementers it can be folded back into the core language (See [Language design philosophy: more than one way?). This makes it possible for the users of the language to evolve the language and the language implementer can cherry pick the best changes.

The question is – should syntax/style be a language feature that is evolved by the end-users? (By making style part of the grammar it becomes part of the syntax) A lisp user would say that it is necessary for a truly powerful language. Macros manipulating s-expressions allow the user to redefine the syntax and expand the language. And in fact most lisps seem to have suffered from the proliferation of syntaxes as occurs in Perl. Then again CLOS represents a crystallization of syntax that would not have occurred if it was not for the ability of the end users to define their own extensions.

I am unsure whether I would prefer a language kernel that is tightly locked down and is loosened up by language extensions or a language kernel that requires extensions to tighten up the syntax. i.e. Do you create an extension to make whitespace significant or create an extension to make whitespace insignificant?

Regardless, high-level languages should be designed for human consumption. Whitespace is significant for humans and thus should be significant for programs. To reduce the wasted time spent defining, adopting and enforcing a code style the language developers should consider adopting a definitive style and enforcing it in the compiler.

Type Systems

2011-05-20T00:00:00+10:00

Types are one of the most fundamental elements of a programming language. A type system classifies values and expressions into types. The type of an element identifies the set of allowable operations that can be performed on a type. The domain of a value is typically restricted by the type of the value. Type systems vary significantly between languages.

This page collects a number of thoughts on type systems and is by no means comprehensive. The original notes were derived from a brilliant reddit comment that I have since lost the link to. Additions and modifications have potentially changed the content significantly from the original source and any inaccuracies were most likely introduced by yours truly.

Type System Dimensions

Static vs. Dynamic

Type checking aims to ensure that operations on a type are in the set of allowable operations and can be performed either during compilation or at runtime. A language where the majority of type checking occurs during compilation is said to be statically typed, while dynamically typed languages perform the majority of the type checking at runtime.

It is typical that the type of every expression can be determined at compile time in a statically typed language. A dynamic language is more likely to rely on a tag associated with a value during run time type checks.

The purpose of statically typed languages is to catch errors early on during the development cycle (i.e. during compilation). In some scenarios it may also be possible to optimize statically typed languages more effectively.

Dynamically typed languages tend to be more flexible than statically typed languages and can execute programs that would be marked as invalid by a static type checker. The downside to this is there are fewer a priori guarantees and development often need to be supported by comprehensive unit testing. (Although some would argue that this is not a downside and all programs should be supported by such practices).

Dynamically typed languages may also make use of more sophisticated type checking that takes advantage of both compile time and run time information. However this often means that the type checking has to occur with each execution of the program which often results in slower execution speed.

The static-dynamic is a spectrum and many static languages support dynamic type checks. Static languages such as downcasting, dynamic type checks and dynamic or “safe” casts (i.e. casts that fail if the type can not be safely cast to specified type).

Manifest vs. Latent

Manifest typing requires the developer to explicitly declare the types of elements in the source code. Latent typing is the opposite, type declarations do not appear in the source code.

Historically statically typed languages were often equated to manifest typing. However type inference systems make it possible to infer the types at compilation time resulting in a latent+static type system. Some recent languages (i.e. Python 3000, Common Lisp, Dylan) make it possible to declare the types but will not check the types until runtime resulting in a manifest+dynamic type system.

Strong vs. Weak

In a strong type system an element can not be coerced into another type without an explicit cast. A weak type system attempts to coerce the elements to the required type through a variety of means.

Safe vs. Unsafe

Safe type systems disallow invalid operations. An unsafe type system make it possible for type errors to occur where an element of one type is manipulated as if it was an element of another type. This is often due to “unsafe casts” or explicit loopholes in the type system.

Unsafe languages exist to support a certain class of system level programming. These languages assume the developer knows what they are doing when they use possibly unsafe constructs and rely on the developer avoiding system corruption.

Nominal vs. Structural Subtyping

Verifying that the type of an element is compatible with another type is central to most type checking systems. The simplest type systems only consider a type compatible if the types are equal or equivalent. However most type systems include a notion of subtyping where the compatibility between types is a transitive relation.

Nominal subtyping is where type relationships are explicitly declared (and named). Structural subtyping occurs when the type relationships are inferred from the structure of types. Most dynamically typed languages are also structurally subtyped.

Languages Classified

C	static, weak, manifest, nominal subtyping
C++	static, weak, manifest, nominal subtyping with structural subtyping available via templates
Common Lisp	dynamic, strong, latent or manifest, nominal and structural subtyping
Erlang	dynamic, strong, latent, structural subtyping
Java	static, strong, manifest, nominal subtyping
Ocaml	static, strong, latent, structural subtyping
Python/Ruby	dynamic, strong, latent, structural subtyping with nominal subtyping available
Scheme	dynamic, strong, latent, structural subtyping with nominal subtyping available
Haskell	static, strong, latent and optional manifest, structural subtyping with nominal subtyping available via newtype

Interpreter Implementation Choices

2011-05-19T00:00:00+10:00

Overview

Interpreters are a popular choice for execution engines in many virtual machine (VM) architectures. Interpreters are popular because they are;

portable: easy to port to new architectures.
simple: a small easy to understandable code base that makes language and VM evolution tractable.
quick to start executing code.

The disadvantage of interpreters is that they have relatively poor execution speed when compared to the equivalent natively compiled code. The performance challenge is usually a result of the low work-to-overhead ratio and poor branch prediction accuracy.

This article uses byte code interpreters as an example and describe different techniques for implementing an interpreter and the impact on execution speed, portability, complexity and start up time.

Representation

Different breeds of interpreter represent instructions differently. Below is several alternative representations of a statement. Interpreters typically walk a tree or iterate over a byte code representation, performing work at each node or instruction as appropriate. (Some interpreters use a series of rewriting rules but these are not considered in this article).

(1)
    push #1
    push #2
    add
    store @var

(2)
    move r1, #1
    move r2, #2
    add r3, r1, r2
    move @var, r3

(3)
      store
        /\
       /  \
    @var  add
          /\
         /  \
        1    2

Different representations of the statement @var = 1 + 2;
(1) stack-based byte code representation,
(2) register-based byte code representation, and
(3) tree-based representation.

Byte code seems to be the most popular representation form. Byte code is compact. Byte code is easy to decode. Byte code is trivial to cache to avoid re-parsing the source language. (Parsing is a relatively expensive operation). Byte code makes it possible to evolve the language syntax without overhauling the underlying instruction set architecture (ISA) too dramatically. Some VMs have a generic ISA that makes it possible for other languages to target the VM with relative ease (assuming that the VM supports a compatible computation model). Given the popularity of the byte code representation form, the remainder of this article will assume this representation.

Most interpreter implementations implement each instruction using a similar pattern. The prologue fetches the arguments from the data stack, registers and/or the environment. The prologue may also prefetch or otherwise prepare for the dispatch following the execution of the instruction. Following the execution of the instruction, results are stored back into the data stack, registers and/or the environment and a fetch+decode+dispatch to the next instruction occurs. The prologue and epilogue constitute the interpreter overhead.

/* Start prologue */
I_add:
{
  int a = *(data_sp++); //retrieve first operand
  int b = *(data_sp++); //retrieve second operand
  int c;
/* End prologue */

/* Start instruction work */
  c = a + b;
/* End instruction work */

/* Start epilogue */
  *(data_sp--) = c; //store result
}
goto **(ip++); //dispatch to next instruction
/* End epilogue */

Example handler for an ‘add’ instruction in a stack-based ISA.

Challenges

Work-to-overhead Ratio

Each instruction in the VM’s ISA results in native code to perform the actual work and overhead native code to traverse the instruction representation. i.e. updating the instruction counter, dispatching to the next instruction etc. The ratio varies depending on design of the ISA. i.e. Is the ISA RISC-like or CISC-like? Is the ISA designed so that the interpreter spends most of it’s time in libraries?

The ratio of useful work performed compared to the overhead of traversing the representation is often low for general purpose interpreters. It would not be unexpected for one VM instruction to translate into 1 or 2 native instructions of useful work and 10 or more native instructions to dispatch to the next VM instruction. This is even more disastrous when you consider that the overhead typically includes one or more difficult to predict branches that stall the instruction pipeline on most modern hardware.

Branch Prediction Accuracy

On modern heavily pipelined hardware there is a heavy cost for mis-predicting a branch. The instruction pipeline is typically flushed and execution is stalled. As a consequence most modern hardware uses some form of branch prediction. Interpreters tend to make heavy use of indirect branches during instruction dispatch and thus the accuracy of indirect branch prediction can significantly impact an interpreters performance. Popular commercially available processors tend to use a Branch Target Buffer (BTB) for indirect branch prediction [ERTL01]. The BTB caches the last target of a branch instruction. The architecture predicts that the next execution of the branch has the same target. With interpreters this assumption rarely holds.

Techniques

Dispatch Strategy

The instruction stream is typically made up of a sequence of VM instructions and immediate values (i.e. the parameters for the instruction). The dispatch or “threading” strategy determines how the execution flows from one VM instruction to the next. There are a number of different strategies; direct threading, indirect threading, token threaded, switched dispatch and replicated switched dispatch.

Direct Threaded Code

Direct threaded code (DTC) [BELL73] encodes each instruction as the address of the code that performs the instruction. Thus flowing from one instruction to the next involves a jump to a value retrieved from the instruction stream. DTC is typically considered one of the fastest dispatch strategies but it does come at the cost of making each instruction the size of an address.

void *program[] = {&&I_const_1, &&I_const_1, &&I_add, ...}
void **ip = program;

goto **ip++;
 
I_const_1: { ... /* Code to handle 'const_1' */ ... } goto **ip++;
I_add:     { ... /* Code to handle 'add' */ ... }     goto **ip++;
...
}

Stack based ISA implemented using DTC dispatch. The program performs 1 + 1 and places the result on the stack.

Indirect Threaded Code

Indirect threaded code (ITC) [DEWAR75] encodes each instruction as the address of a cell in a lookup table. ITC adds one more level of indirection to DTC and thus typically results in more overhead during dispatch. ITC does have the advantage that the execution engine can be modified by changing the look up table without modifying all the generated code. This would make it possible to switch between normal execution, profile gathering execution or debug execution modes by simply overwriting the lookup table.

static void *lut[] = {&&I_const_1, &&I_add, ...};

...

void * program[] = {lut, lut, lut + 1, ...}
void **ip = program;

goto ***(ip++);
 
I_const_1: { ... /* Code to handle 'const_1' */ ... } goto ***(ip++);
I_add:     { ... /* Code to handle 'add' */ ... }     goto ***(ip++);
...
}

Stack based ISA implemented using ITC dispatch. The program performs 1 + 1 and places the result on the stack.

Token Threaded Code

Token threaded code (TTC) encodes each instruction as a byte that indicates the offset of a handler in a lookup table. Token threaded code is a much more compact representation than the DTC or ITC strategies. Like ITC, TTC can support multiple execution modes by modifying the lookup table.

typedef enum 
{
  const_1, add, ...
} instruction_t;

...

static void *lut[] = {&&I_const_1, &&I_add, ...};

...

instruction_t program[] = {const_1, const_1, add, ...}
instruction_t *ip = program;

goto *lut[*ip++];
 
I_const_1: { ... /* Code to handle 'const_1' */ ... } goto *lut[*ip++];
I_add:     { ... /* Code to handle 'add' */ ... }     goto *lut[*ip++];
...
}

Stack based ISA implemented using TTC dispatch. The program performs 1 + 1 and places the result on the stack.

Switch-based Dispatching

Switch-based dispatching (SBD) represents each instruction as a byte. There is a single loop in which a switch statement is used to dispatch to the handler for each instruction. Like TTC, the representation is compact but the most significant advantage is that it can be implemented in almost any programming language. The previously described dispatch strategies require special support from the compiler (i.e. GCC’s “Labels as Values” extension [GCC]) or a small amount of platform specific assembly code.

typedef enum 
{
  const_1, add, ...
} instruction_t;

...

instruction_t program[] = {const_1, const_1, add, ...}
instruction_t *ip = program;

while( 1 )
{
  switch (*ip++) 
  {
    case const_1: { ... /* Code to handle 'const_1' */ ... } break;
    case add:     { ... /* Code to handle 'add' */ ... }     break;
    ...
  }
}

Stack based ISA implemented using SBD dispatch. The program performs 1 + 1 and places the result on the stack.

Replicated Switch-based Dispatching

Replicated switch-based dispatching (R-SBD) is a variant of SBD that attempts to minimize indirect branch mispredictions. SBD uses a single indirect branch through which all instructions pass but R-SBD replicates the switch statement for each instruction (and includes an unconditional jump in the switch statement to instruction handling code). SBD results in a near 100% misprediction rate using the BTB where as R-SBD can result in a lower 50% mis-prediction rate [ERTL01].

typedef enum 
{
  const_1, add, ...
} instruction_t;

...

instruction_t program[] = {const_1, const_1, add, ...}
instruction_t *ip = program;

switch (*ip++) 
{
  case const_1: goto I_const_1;
  case add: goto I_add;
  ...
}
  
I_const_1: 
{ ... /* Code to handle 'const_1' */ ... }
switch (*ip++) 
{
  case const_1: goto I_const_1;
  case add: goto I_add;
  ...
}
I_add: 
{ ... /* Code to handle 'add' */ ... }
switch (*ip++) 
{
  case const_1: goto I_const_1;
  case add: goto I_add;
  ...
}
...

Stack based ISA implemented using R-SBD dispatch. The program performs 1 + 1 and places the result on the stack.

Summary

The performance of different dispatch methods varies between hardware configurations and architectures, VM ISA designs, execution workloads and other interpreter design decisions. For example, the low memory pressure of SBD, may result in an interpreter that outperforms DTC on certain workloads or if the system has small caches. The only real way to determine the most appropriate strategy is to measure the performance in realistic scenarios. [ERTL07] measured the performance of different dispatch strategies across a range of architectures and compared it to the standard “subroutine” dispatch strategy (i.e. a normal function calls rather than interpretation). Somewhat expectantly, DTC outperformed “subroutine” dispatch strategy in most scenarios. This just goes to show that experimental investigation can yield surprising non-intuitive results.

Inlined Instructions

Inlining instructions is a technique for eliminating the dispatch overhead associated with an instruction. The interpreter identifies the native instruction sequence for handling a particular VM instruction. The native instruction sequence is then copied into a new handler. The new handler may actually contain the native instruction sequences for several VM instructions and the control flow can flow from one VM instruction to the next without any dispatch overhead. Taken to the extreme, where the sequence of VM instructions that make up each “function” is copied into a single handler, and the interpreter becomes a poor mans JIT compiler.

Inlining instructions is not without it’s problems. Typically some form of cache is used to avoid regenerating the inlined sequences multiple times. This approach can dramatically increase the memory pressure of the interpreter as more VM instructions are concatenated into handlers. If a function or method is not invoked multiple times then the performance benefit of eliminating the dispatch is typically offset by the cost of generating the inlined sequences and caching the result.

Inlining instructions has several portability problems. Firstly, compiler specific extensions are typically needed to identify the start and end of instruction handler code (i.e. GCCs “Labels as Values” extension [GCC]). Secondly, not all code is position independent code (PIC) and thus not all code can be safely inlined. Code that is compiled with relative calls or branches that have targets outside the sequence being copied will not work as expected.

Depending on the compiler, compiler configuration options and hardware architecture, relative addresses can be used when making c function calls. The C function call may have been explicitly inserted by the programmer as part of the implementation of the instruction handler or they may be implicitly generated by the compiler. For example, the GCC compiler may implement the “divide by a long” operation as an hidden internal c function call on some platforms (i.e. x86).

Another problem arises when the interpreter is compiled at different levels of optimisation. Conditional code in a handler such as the C code if( ... ) { ... } may generate relative jumps to the end of the handler at low levels of optimization. At higher levels of optimization the jump becomes a relative jump into the dispatch code. As a result this code can be inlined at low levels of optimization but will fail at higher levels of optimization.

Inlining code offers a speed advantage but requires an in depth knowledge of compiler implementation details to identify which sequences compile down to PIC. As the compilers methods for generating code can change between releases this ultimately results in a far less portable product and portability is one of the advantages of writing interpreters in the first place. Several projects that have used this approach (i.e. QEMU) eventually begin to move away from this design.

/* Instruction Implementations */
I_const_1_start: 
{
  *(data_sp++) = 1;
}
I_const_1_end: 
goto **(ip++);

I_add_start: 
{
  int a = *(data_sp++);
  int b = *(data_sp++);
  int c;
  c = a + b;
  *(--data_sp) = c;
}
I_add_end: 
goto **(ip++);

...

/* Create an inline sequence of const_1, const_1, add */
size_t const_1_size = &&I_const_1_end - &&I_const_1_start; 
size_t add_size = &&I_add_end - &&I_add_start; 

void *sequence = malloc(const_1_size + const_1_size + add_size); 
memcpy(sequence + 0, &&I_const_1_start, const_1_size); 
memcpy(sequence + const_1_size, &&I_const_1_start, const_1_size); 
memcpy(sequence + const_1_size + const_1_size, &&I_add_start, add_size); 
... 

/* Jump to the start of inlined sequence to start execution */ 
goto **sequence;

Example of creating an inline sequence of const_1, const_1, add instructions.

Super Instructions

Combining several VM instructions into superinstructions or “macro” instructions is a technique that has been used to reduce code size, reduce the overhead of dispatch and argument access [PRO95],[HOOG99],[PIU98],[GREGG03]. The superinstruction replaces the sequence of the component instructions either when the byte code is loaded or after the initial parsing of the source language.

(1)
    load @var
    push #1
    add
    store @var

(2)
    load @var
    push_1
    add
    store @var

(3)
    load @var
    inc
    store @var

(4)
    inc @var

Different instruction sequences to increment a variable:

(1) using primitive operations,
(2) using a superinstruction to push a 1 onto the stack,
(3) using a superinstruction to increment the value on the top of the stack, or
(4) using a superinstruction to increment the value of a variable.

The figure above presents several sequences of instructions for incrementing the value of a variable. Each successive version uses superinstructions that take on more responsibility. In (2) the push #1 sequence (i.e. instruction byte plus a literal integer value) becomes push_1, a single instruction byte. In (3) the push_1; add sequence becomes inc. In (4) the entire sequence is reduced to one superinstruction.

With each successive version the size of the VM code has decreased. After (2) the number of pushes and pops onto the stack decrease, reducing the overhead associated with passing parameters to instructions. After (2) the amount of useful work per VM instruction has increased and thus the proportion of dispatch overhead is decreased.

The tradeoff is that as superinstructions become more specific, they are less likely to be used. An implementer needs to strike a balance between the work achieved by the instruction and usefulness of the superinstruction.

It should be noted that there are also constraints on the type of instructions that can be combined into a superinstruction. Most approaches disallow instructions that alter the control flow from being merged into a superinstruction unless it is the last VM instruction in a the superinstruction. Instruction sequences that cross a basic block boundary are typically not candidates for merging as it can make it difficult to handle a jump to the start of the second basic block.

The code to handle the superinstruction can either be generated at build time or at run—time. The runtime or dynamic approach uses instruction inlining with all the associated costs and benefits.

Generating the superinstructions at build time means that the interpreter needs to know which instructions are good candidates for superinstructions ahead of time. This is not typically a problem as profiling and common sense can often suggest which instructions make good candidates for superinstructions. Interpreter generation frameworks such as vmgen [GREGG03] provide built—in profiling to identify candidate superinstructions.

External or Internal?

The other major consideration for superinstructions is whether they are exposed outside the interpreter. Of course this does not make any sense if the interpreter does not define the ISA or byte code format as part of the external specification.

Internal superinstructions are not part of the external specification. Internal superinstructions replace normal instructions as the byte code is loaded into the virtual machine. They have the advantage that they can evolve faster and change to meet changing workloads or architectures and the implementation is not constrained by the initial design of the VM ISA.

The Java VM instruction set includes several superinstructions as part of the external specification. The 2 byte instruction ldc + [constant pool value] loads a constant value onto the stack. The Java specification also supports the 1 byte instruction iconst_1 that puts the constant 1 on the stack. The second form is likely used because it is a frequently occurring operation in a java program and it decreases the size of the code format.

Of course there is nothing to stop the interpreter from supporting a set of external superinstructions and another set of internal superinstructions. In this fashion the VM can gain the advantage of increased flexibility of internal superinstructions where needed as well as the reduced code size that comes with external superinstructions.

De-specializing

De-specializing a superinstruction replaces a superinstruction with it’s component VM instructions. This may be desirable when there is a need to reduce the number of distinct instructions. Typically the specialization or superinstructions that are de-specialized were originally specialized to reduce code size, not necessarily to improve performance. De-specializing an instruction can make the introduction of other superinstruction sequences more performance effective [CASEY07]. The CellVM, a JVM for the Cell Broadband Engine architecture de-specializes the load/store VM instructions for this reason [WIL08].

Instruction Replication

Replicating the code to handle a VM instruction multiple times, has been proposed as a mechanism for improving BTB prediction accuracy [CASEY07]. Each replica uses a separate indirect branch to dispatch to the next instruction. Therefore each replica has a separate BTB entry. Each instruction instance attempts to make use of a different replica.

Without replication, if an instruction appeared multiple times within a loop the BTB mis-prediction rate is close to 100%. Using a separate replica for each instruction instance can dramatically improve the accuracy of branch prediction. There will still be some mis-predictions if the number of replicas in a loop is less than the number of instruction instances.

Increasing the number of replicas increases the size of the interpreter. This can adversely impact the time it takes for the native compiler to build and optimize the code. In some cases the resulting code growth may also cause performance problems due to increased memory pressure. However, at least for some domains the benefit of increased BTB prediction accuracy out weighs any performance degradations due to the increased size of the generated code [CASEY07].

While I am unaware of any published results, it is expected that an appropriate profiler can identify which particular instructions could benefit from replication and suggest suitable number of replicas. An enhanced version of vmgen [GREGG03] (or other interpreter generator) could feedback profiling data into the build process much like it feeds back suitable superinstructions.

Replicas are typically generated statically at build time but some research has looked at replicating instructions dynamically at runtime. The dynamic approach uses instruction inlining with all the associated costs and benefits.

Manual Branch Prediction

Some modern processors make it possible for the software developer to influence the branch prediction logic on the processor, thus limiting or eliminating mispredictions. Eliminate the mis-prediction and several other techniques become obsolete. R-SBD no longer has an advantage over SBD. Replicating instructions no longer improves performance and may cause degradation due to code bloat.

Some modern ISA’s (i.e. IA64 and Power/PPC) use split branches to try and reduce the mis-prediction penalty. There is a separate prepare-to-branch instruction and a branch instruction. As long as the software schedules a prepare-to-branch instruction prior to the branch then the indirect branches can be executed without a stall. In interpreters that have a low work-to-overhead ratio, it may be necessary to schedule a prepare-to-branch instruction in instruction N-1 with target of N+1 so that it is available in instruction N. The IBM POWER3 processor implements this with a special branch target register that can be set to target to avoid a misprediction penalty [OGATA02] branch hints feature of the Cell processor is a similar strategy, it allows the program to explicitly set BTB entry [WIL08].

Summary

Interpreters are are used because they are simple to implement, portable across platforms and quick to start up but the performance does not compare with native code. The article outlines several different trade offs that can be made while building an interpreter to improve the execution speed at the cost of decreasing the portability and simplicity of the interpreter or increasing the start up time of executed code. The described techniques include; Dispatch Strategies, Inlined Instructions, Super Instructions, Instruction Replication and Manual Branch Prediction. There are other techniques that can significantly impact the interpreter implementation such as stack caching and aligned access vs non-aligned access that have not been explored.

The actual costs and benefit of any particular design choices for a particular interpreter will depend dramatically on the language being interpreted, the expected workload and the hardware environment. In a perfect world an interpreter generator, such as vmgen [GREGG03], would take a virtual machine specification, several sample programs from which to determine the workload and would be able to build an interpreter that was optimized for the host environment, workload and language. The utility of such an approach may not be high but it would be a fun are to explore.

Bibliography

BELL73: J. R. Bell. “Threaded code”. Communications of the ACM, 16(6):370–372, 1973.
CASEY07: K. Casey, M. A. Ertl, and D. Gregg. “Optimizing indirect branch prediction accuracy in virtual machine interpreters”. ACM Transactions on Programming Languages and Systems (TOPLAS), 29(6):37, 2007.
DEWAR75: R. B. K. Dewar. “Indirect threaded code”. Communications of the ACM, 18(6):330–331, 1975.
ERTL01: M. Anton Ertl and David Gregg. “The Structure and Performance of Efficient Interpreters”, Journal of Instruction-Level Parallelism, Vol. 5, November, 2003.
ERTL07: M. Anton Ertl. “Speed of various interpreter dispatch techniques v2”, 2007. http://www.complang.tuwien.ac.at/forth/threading/.
GCC: “Labels As Values”, 2008. http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
GREGG03: D. Gregg and M. A. Ertl. “A language and tool for generating efficient virtual machine interpreters”. In C. Lengauer, D. S. Batory, C. Consel, and M. Odersky, editors, Domain-Speciﬁc Program Generation, volume 3016 of Lecture Notes in Computer Science, pages 196–215. Springer, 2003.
HOOG99: J. Hoogerbrugge, L. Augusteijn, J. Trum, and R. V. D. Wiel. “A code compression system based on pipelined interpreters”. Softwware – Practice and Experience, 29(11):1005–2023, 1999.
OGATA02: K. Ogata, H. Komatsu, and T. Nakatani. “Bytecode Fetch Optimization for a Java Interpreter”. In ASPLOS-X: Proceedings of the 10th international conference on Architectural support for programming languages and operating systems, pages 58–67, New York, NY, USA, 2002.
PIU98: I. Piumarta and F. Riccardi. “Optimizing direct threaded code by selective inlining”. SIGPLAN Notices, 33(5):291–300, 1998.
PRO95: T. A. Proebsting. “Optimizing an ansi c interpreter with superoperators”. In POPL ’95: Proceedings of the 22nd ACM SIGPLAN-SIGACT symposium on Principles of programming languages, pages 322–332, New York, NY, USA, 1995.
WIL08: K. Williams, A. Noll, A. Gal and D. Gregg. “Optimization strategies for a java virtual machine interpreter on the cell broadband engine”. In CF ’08: Proceedings of the 2008 conference on Computing frontiers, pages 189-198, New York, NY, USA, 2008.

Embarking on a FOSS project

2011-05-16T00:00:00+10:00

When building a Free / OpenSource Software project it is important to optimize for now. If you don’t optimize for now there is no guarantee you get to tomorrow. Limiting today’s solution by tomorrows constraints means you can not fully utilize the strengths of your current situation. This may result in the system failing to meet today’s problems and thus never getting to tomorrow. (i.e. Why design a system for 1,000 users when 10 will do for now? Why design for 1,000,000 users when 1,000 will do?)

For a project to survive without corporate sponsorship you also need to optimize for fun. People program best when they are having fun, when they are under no deadlines, when there is no stress. So heavy weight approaches that increase the gap between action and response should be minimized. This means reducing the amount of boilerplate / “bureaucracy” coding, having simple steps to get started and having a short loop to getting the code included in the mainline.

This may mean having a build server that is constantly online testing changes and applying them if they introduce no new errors. People could submit to the build server against a particular version. If the build and testing loop succeeds it is submitted to some of the core group for inclusion in mainline, otherwise the submitter is informed of the failures.

So no matter what the primary goal of the project, the project may benefit by optimizing for now and optimizing for fun.