Award Papers

Afterwards, I attended the session with the awarded OOPSLA papers. The Hybrid Partial Evaluation talk presented an approach to avoid the typical cost of use of reflection or ‘interpretation’. The presentation of SugarJ: Library-based Syntactic Languages felt like a déjà vu. I did not get where it is different from Helvetica other than that it is for Java. The third paper on Reactive Imperative Programming with Dataflow Constraints was interesting in that it used also memory protection tricks to realize a reactive model in C++. The last presentation: Two for the Price of One: A Model for Parallel and Incremental Computation was very interesting. I have not used incremental computations as far as I am aware of anywhere other than for course work, but bringing it together with parallel programming in a single programming model, gives plenty of opportunities for super-linear speedups.

Parallel and Concurrent Programming

The second session of the day was on parallel and concurrent programming. Kismet: Parallel Speedup Estimates for Sequential Programs tackled the problem to get an idea of what opportunities for parallelism are available in a given program without having to change the used algorithms and approaches to much. For that, it uses data dependency analysis to characterize the critical path on a data-flow level. Since that usually does not give realistic results because of overestimation of parallelizability, they use in addition a hierarchical model of loops and the knowledge of the available hardware parallelism to better predict possible speedups.

The second and the third talk where almost identical in terms of problem and goal. Essentially, they provide the necessary infrastructure to run different variants of sequential implementations in parallel and then chose either the winner in terms of runtime or precision. These approaches are especially interesting if the available algorithms have very different properties for different input or input sizes. For instance, some mathematical algorithms just do not converge to a solution for certain inputs while they are very fast for others.

The last talk of the session discussed Scalable Join Patterns. Join patterns are an old approach to describe synchronization mechanism flexibly and declaratively. The presented work provided a scalable implementation approach that seems to work quite well and when they would use a compilation based approach for the patters, I guess it could be a very feasible and flexible replacement for standard synchronization mechanism provided as libraries.

Panel

Instead of attending the third paper session of the day, I attended the panel on Multicore, Manycore, and Cloud Computing: Is a new Programming Language Paradigm required?. Well, it was entertaining Nothing really new, no surprising arguments as far as I recall, but certainly interesting to watch. I think, they also recorded it. So it might be floating around the web soon.

I attended the Transitioning to Multicore workshop.

For me the most interesting talks were two empirical studies presented by Fernando Castor. The first talk was about a controlled experiment with students using coarse-grained locks (or actually MVars) and STM in Haskell. While such experiments are usually biased in some way or another, he presented an interesting set of anecdotes along with the actual results. Notably, he observed similar mistakes done by the students as we observed as part of our Multicore Programming course. It seems to be hard to define the right granularity of atomicity, especially when an all-inclusive atomic section is not applicable. His second talk was about analyzing the use of concurrency constructs in open source software. While this was still very early work, it shows how gradual the adoption of libraries like java.util.concurrent is in such software projects.

The other presentations included approaches to minimize conflicts in transactional systems, automated support for memorization on top of STM, and how Intel’s TBB can be used to express parallel pipelined programs with a focus on which kind of pipelines can be easily expressed.

For me, the workshop ended with a panel discussion featuring Doug Lea, Matt Sottlie, Suresh Srinivas, and Tucker Taft. The most interesting point made was that one of the goals should be to facilitate all kind of different flavors of parallel programming (of course! ) Matt pointed out in his introduction that parallel programming models are all good and well, and that being able to spilt up a problem in threads is important, but that the memory wall is often not discussed and that feeding enough data to the threads to keep them busy is becoming increasingly harder. Another point made in different variations is the importance of tools, their accessibility to developers, and their integration with runtimes and hardware. Doug mentioned also that the hardware vendors are making life harder for everyone without apparent reason by not using standards for instance to number cores. Especially since they do not provide the mechanisms to query the cache design properties and core arrangements that inhibits portable and reliable performance for mechanism like work-stealing schedulers.

As I said, this is a position paper, which hopefully provokes discussion. Feedback of any kind is welcome, and I am happy to adapt my presentation accordingly.

Abstract

While parallel programming for very regular problems has been used in the scientific community by non-computer-scientists successfully for a few decades now, concurrent programming and solving irregular problems remains hard. Furthermore, we shift from few expert system programmers mastering concurrency for a constrained set of problems to mainstream application developers being required to master concurrency for a wide variety of problems.

Consequently, high-level language virtual machine (VM) research faces interesting questions. What are processor design changes that have an impact on the abstractions provided by VMs to provide platform independence? How can application programmers’ diverse needs be facilitated to solve concurrent programming problems?

We argue that VMs will need to be ready for a wide range of different concurrency models that allow solving concurrency problems with appropriate abstractions. Furthermore, they need to abstract from heterogeneous processor architectures, varying performance characteristics, need to account for memory access cost and inter-core communication mechanisms but should only expose the minimal useful set of notions like locality, explicit communication, and adaptable scheduling to maintain their abstracting nature.

Eventually, language designers need to be enabled to guarantee properties like encapsulation, scheduling guarantees, and immutability also when an interaction between different problem-specific concurrency abstractions is required.

• Which Problems Does a Multi-Language Virtual Machine Need to Solve in the Multicore/Manycore Era?, Stefan Marr, Mattias De Wael, Michael Haupt, Theo D’Hondt, Proceedings of the 5th Workshop on Virtual Machines and Intermediate Languages, USA, ACM (2011), to appear.
• Paper: PDF
  ©ACM, 2011. This is the author’s version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. To appear.
• BibTex: BibSonomy

Slides

Below you can find the abstract and slides.

Abstract

The manycore future has several challenges ahead of us that suggest that fundamental assumptions of contemporary programming approaches do not apply anymore when scalability is required.

Sly is a language prototype designed to experiment with the inherently nondeterministic properties of parallel systems. It is designed to enable programmers to embrace nondeterminism instead of guiding them to fight it. Nature shows that complex system can be built from independent entities that achieve a common goal without global synchronization/communication. Sly is design to enable the prototyping of algorithms that show such emerging behavior. It will be introduced in the first part of the talk.

The second part of the talk will focus on the underlying problems of building virtual machines for the manycore future, which allow to harness the available computing power. The RoarVM was design to experiment on the Tilera TILE64 manycore processor architecture which provides 64 cores and characteristics that are distinctly different from today’s commodity multicore processors. Memory bandwidth, caches and communication are the biggest challenges on such architectures and this talk will give a brief overview over the design choices of the RoarVM which tackle the characteristics of the TILE64 architecture.

 

Acknowledgement: Sly and the RoarVM were designed and implemented by David Ungar and Sam Adams at IBM Research.

The following introduction and analysis of the Sly3 programming language was written by Pablo Inostroza Valdera as part of his course work for the Multicore Programming course of Tom Van Cutsem. The assignment was to write a blog post about a topic of their own choice, and I repost Pablo’s work here with his permission to spread the word about Sly a bit wider. We made his article also available as part of his work for the Renaissance project itself.

Multicore Programming, Course Work

The Sly3 Programming Language

Pablo Inostroza Valdera

< pinostro _ vub.ac.be >

23 June 2011

Introduction

Sly3 is a Smalltalk dialect that features two concepts in order to deal with parallelism: ensembles, which are collections of objects that can receive parallel messages, and modifiers, which decorate messages in order to modify their parallel behavior (adverbs) or to specify how to handle reductions (gerunds). In this article we analyze Sly3‘s programming model.

Sly3 is a language being developed in the context of the Renaissance Project, at IBM. With Sly3, their authors David Ungar and Sam Adams explore abstractions for nondeterministic parallel programming. Sly3 is the experimental successor of LY, a javascript-like interpreted language that was implemented on top of Smalltalk[UA10]. As the 3 in Sly3 indicates, Sly itself underwent already three iterations of design. The main idea behind the design of Sly3 is that multicore programming is commonly addressed by restricting the nondeterminism parts and trying to enforce strict determinism. As an example of this, Ungar and Adams refer to the actors paradigm. While the actor model certainly adds some order to concurrent computations, the truth is that some nondeterminism still persists because the global order in which messages arrive to an actor is nondeterministic. They proposed that instead of trying to restrict the nondeterminism, it should be embraced. The Ly language and, later on, the Sly3 language are steps towards that direction. In this article we discuss the latter.

Ensembles, or How to Represent A Flock of Birds

Sly3‘s key elements were conceived by observing the nature. Think of a flock of birds, an ant colony or a school of fishes. These are all examples for a multitude of independent agents, acting in a nondeterministic way, whose aggregated behavior is more complex than that of the individuals. In other words, a more complex behavior emerges. The idea of a whole formed from independent units is key to Sly3, and it has been reflected in the concept of an ensemble. An ensemble is a collection of objects, subject of receiving messages as a whole. In the following example, we create an ensemble and execute an operation on it:

  numbers := Sly3Ensemble with: {1. 2. 3. 4. 5}.
  squaredNumbers := numbers squared.
  

This code yields: %{1. 4. 9. 16. 25}. Recall that the curly braces represent an array in Smalltalk. In Sly3, curly braces preceded by % denote an ensemble.

Notice how the ensemble received a message as a whole, but it acted on each individual in order to produce a new ensemble with all of the elements squared. It is not surprising to know that the default behavior of this mapping is parallel, i.e., a different thread of execution is triggered for each individual computation. The standard execution strategy in this this simple example is as follows:

• The message was delegated to members of the ensemble, creating a parallel process for the evaluation of each of the messages. We can say that each member was treated individually and was executing its own task.
• For generating the final result, a new ensemble was created from the results of all the tasks of the previous step. We can say that we are ensembling together all the individual results.

Notice that we have put in bold letters two words: individually and ensembling. We have done so, because both words characterize a strategy for handling a parallel computation. Actually, this is the default strategy in Sly3, but the programming model was designed to be able to customize these behaviors.

Adverbs and Gerunds, or How to Modulate Parallel Behavior

The basic model of message handling for an ensemble is:

1. The ensemble that receives the message is treated in accordance to its adverb. A receiver’s adverb precedes the message name. In the absence of an explicit one, the default adverb for receiver, namely individualLY, is used. We elaborate on the meaning of individualLY in subsequent paragraphs, important here is to note that adverbs’ names always end in LY.
2. If there are operands, they have to be treated in accordance with their adverbs. An operand adverb follows the message name. In the absence of an explicit one, the default adverb for operands, namely wholLY, is used.
3. The operation is executed according to an overall strategy, also determined by an adverb.
4. The result of the operation is reduced in accordance to a gerund. In the absence of an explicit one, the default gerund, namely ensemblING, is used. Gerunds’ names always end in ING.

Regarding the point 3, it suffices to mention that currently there are only three overall strategies, namely, serially, plainly and the default one, which we can call parallelly. Note that the metaphor of the adverb is taken to an extreme in Sly3. Many words that do not sound like adverbs are adverbialized in order to fit in the conceptual framework. Serially forces serial executions, so no processes/threads are spawned to compute the results. This can be useful either for semantic reasons or when the cost of parallel execution is to high, i.e., when we are below the sequential threshold. The adverb plainly can be used to turn off ensemble behavior, and therefore, to treat the ensemble as a collection (e.g., we could ask for the size of an ensemble by using plainly, and this would not imply sending a message to each of its members). For the sake of brevity, we are not going to discuss the overall strategies further, since they are not relevant for grasping the essence of the Sly3 programming model.

The syntax of Sly3 is cumbersome, so next we present some examples in order to provide a more clear idea of how to express things in this language. Let’s analyze them in the light of three of the steps presented before (1, 2 and 4; 3 is excluded since are not going to discuss the overall strategy). In order to guide our analysis, figure 1 presents a table with brief descriptions of some of the main adverbs in Sly3, and their impact on the message evaluation process. We have not included a similar table for gerunds, because their names are in general more self descriptive.

Example 1

    %{true. true. false. true} andING
  

• In this example, there are no adverbs specified, therefore, the receiver’s adverb is the default one, i.e., individually. This implies that the processing of the members is done independently (i.e. in different Smalltalk processes).
• There are no arguments, therefore, no argument’s adverb.
• There is a gerund andING that acts on the result of the operation reducing the independent results coming from different processes. As its name indicates, andING performs logical and over the members of the resulting ensemble. Notice that there no actual message specified here, thus, andING is applied to unchanged set of members of the ensemble.
• Therefore, the result of this operation is: false.

Example 2

    %{1. 2. 3} plusRoundLY: %{10. 20. 30}
  

• Here are no adverbs specified for the receiver, therefore, the receiver’s adverb is the default one, i.e., individually. This implies that the processing of the members is done independently (i.e. in different processes/threads).
• roundLY is an argument to the operand (%10. 20. 30 ). This adverb says: create a process/thread for each combination of the receiver’s member and the argument’s member; acting as a cartesian product.
• There is no gerund, which means that the default one (ensemblING) is used.
• Therefore, the result of this operation is: %{11. 12. 13. 21. 22. 23. 31. 32. 33}.

Example 3

    %{1. 2. 3} valueLY: [   | x * 10]
  

• valueLY is an argument of the receiver, therefore, the receiver has to be mapped to a new ensemble using the given block as the mapper.
• There are no arguments, therefore, no argument’s adverb. Recall that the block is an argument to the adverb. As we can see, the problems of Sly3′s syntax become evident in these cases.
• Therefore, the result of this operation is: %{10. 20. 30}.

An Overview of Sly3′s Implementation

In order to have a comprehensive view of the spectrum of the current custom behaviors available for direct use, in figure 1 we show the hierarchy of gerunds and adverbs that we can find in the current image of Sly3. Notice that this forms a restricted vocabulary that we can use as a basis of more complex strategies, in a LEGO-like way. In fact, we can see this hierarchy as a custom domain-specific language suited for the description of common strategies for handling parallelism.

Figure 1: The hierarchy of modifiers of Sly3.

Based on what we have discussed so far, we can characterize Sly3 as:

• An Object-oriented language, descendant of Smalltalk, which incorporates ensembles as first-class entities to model parallelism.
• It features parallelism by default. As soon as a message is sent to an ensemble, it is assumed that the processing will be spawned as independent tasks over the members of this ensemble.
• Implicit parallelism. The processes that handle messages for ensembles are spawned under the hood, and programmers interact without having to switch to a parallel mindset.
• The way the receiver and the operands of a message are treated is specified by a set of adverbs.
• The way the result is reduced is specified by a set of gerunds.
• The messages are not reified as for instance in the case of Communicating Sequential Processes or actors.
• Communication is assumed to be synchronous.
• The processes are not reified as in the case of actor-based computing.

A Note on the Evaluation Process

The Sly3 language is implemented as an extension of a Smalltalk Virtual Machine, the RoarVM. The current strategy is that whenever a message to an ensemble is detected, a custom message dispatcher is launched in order to handle it. Thus, the message is parsed and evaluated at runtime. The message is analyzed by partitioning the receiver according to its adverb, and pairing it with the arguments according to arguments’ adverbs. Then, the actual operation is executed in whichever set of operands resulted from the previous processing. The final result is reduced according to the gerund. When we use the expression according to, it is worth to highlight that the actual behavior is encoded in the classes of the gerunds an adverbs.

Below we give as example the implementation of the totallING gerund. In the image it is the only method of the class Sly3ModTotalling. Notice, that it nothing more but the implementation of a simple summing policy.

    ; method of the class Sly3ModTotalling
    reduceForEvaluator: ev
      "Sum the elements in results and return the result.
      Assumes these elements understand +."
      | result results |
      results := ev result.

      results isEmpty ifTrue:
        [ self error: 'No members, how should we handle?  proceed for nil'.  
          ^nil ].

      result := 0.
      results do: [ :each | result := each + result ].
      ev result: result
  

Below we give the code for the two relevant method of the Sly3ModCollectionly class that implements the collectionLY adverb in Sly3. Although it is necessary to deeply understand the behavior of the process of evaluating a message in order to understand this code, at least we can have an intuition that what is happening at some point is that a collection is created and returned (see line 17). Eventually, this is how the creation of a collection from an ensemble (which is what collectionLY does) is implemented.

    ; methods of the class Sly3ModCollectionly
    amendOperandTuples: operandTuplesIncludingThisOne
    	| ens |
    	ens := (operandTuplesIncludingThisOne collect: [:ot | ot last]).
    	^ operandTuplesIncludingThisOne collect: [:ot |
    		  ot copy removeLast; addLast: ens; yourself]


    extendOperandTuples: operandTuplesSoFar 
               operand: operand
               membersOrNil: operandMembers
    	| mems |
    	mems := operandMembers ifNil: [operand] 
                                ifNotNil: [operandMembers].
    	^ operandTuplesSoFar
    	    ifEmpty: [OrderedCollection with: 
                             (OrderedCollection with: mems)]
    	    ifNotEmpty: [ operandTuplesSoFar collect: 
                               [:tuple | tuple copy addLast: mems; yourself]]
  

Therefore, each modifier in Sly3 is self descriptive and fully determines the impact that their presence provokes on the evaluation process.

Implementing MapReduce in Sly3

In order to show an example of how to use Sly3, we have implemented a naive MapReduce framework. Take a look at the course notes for an Erlang implementation of the same examples.

It is worth to stress that the conciseness of the code that we eventually obtain is a consequence of both using Sly3 and the application of an Object-oriented approach. The framework relies on ensembles that receive messages. By doing that, the messages are implicitly sent in parallel, so we do not have to specify this in the code. We next discuss the core excerpts of the code.

Imagine two well-known applications of MapReduce. First, we want to count the number of occurrences of words in a set of documents. Another application is to know in which documents some words are found. In order to do that, the MapReduce paradigm requires us to provide the problem-specific knowledge by means of a map procedure and a reduce procedure.

Since Sly3 being an object-oriented language, we have modeled the MapReduce problem-independent behavior as a class MapReduce. Any particular implementation has to subclass this class and override two abstract methods, namely, mapForKey:value: and reduceForKey:values:.

Facing the problem of counting words in a document, below are the methods of the class CountWordsMapReduce that implement this behavior in Sly3. Notice that for sakes of simplicity, we have modeled a filesystem as a Dictionary whose keys are strings that represent file names and whose values are ensembles corresponding to the set of words in a file.

    "Specific methods of the class CountWordsMapReduce"
    mapForKey: ignore value: fileName
    	| words |
    	words :=  self consult: fileName.
    	^ words valueLY: [:y| {y. 1}]

    reduceForKey: word values: counts
    	^ {word. counts totallING}

    consult: file
    	^ files at: file
  

Facing the problem of indexing the texts using the words that they contain, below are the methods of the class TextIndexingMapReduce that implement this behavior in Sly3.

    "Specific methods of the class TextIndexingMapReduce"
    mapForKey:  ignore value: fileName
    	|words |
    	words :=   self consult: fileName. 
    	^ words valueLY: [:word| {word. fileName}]

    reduceForKey: word  values: names
    	^ {word. names members asSet}

    consult: file
    	^ files at: file
  

Notice that in both cases, it suffices to use combinations of the existing adverbs to achieve the desired functionality (see lines 5 and 8 of the first listing and line 5 in the second one). Moreover let’s now analyze the class MapReduce, that implements all the machinery of our naive MapReduce implementation.

    "Specific methods of the class MapReduce"
    dictionaryToList: dict
    	|lst|
    	lst := OrderedCollection new.
    	dict associationsDo: 
              [:assoc| lst add:{assoc key. 
                       Sly3Ensemble 
                         withMembersFrom: assoc value}].
    	^ Sly3Ensemble withMembersFrom: lst

    do: input
    	|dict  nonFlatValues flatValues intermediateValues|
    	nonFlatValues:= input valueLY:  [ :pair |
         self mapForKey: (pair at: 1) value: (pair at: 2)].
    	flatValues := nonFlatValues members 
          inject:  (OrderedCollection new) 
          into: [:acc :cur | 
                  acc addAll: 
                        cur members asOrderedCollection. 
                  acc].
    	dict := self groupValuesByKey: flatValues.
    	intermediateValues:= self dictionaryToList: dict.
    	^ intermediateValues valueLY:
           [ :pair | self reduceForKey: (pair at: 1) 
                          values: (pair at: 2) ]

    groupValuesByKey: keyValues
    | dict|
    dict := Dictionary new.
    keyValues do:[:keyValue |
    	| key value |
    	key := keyValue at: 1.
    	value := keyValue at: 2.
    	(dict includesKey: key)
          ifTrue: 
            [(dict at:key) add: value]
          ifFalse: 
            [dict at: key 
                  put: (OrderedCollection newFrom: {value})] .
    	].
    ^ dict

    mapForKey: key value: value
    	self subclassResponsibility.

    reduceForKey: key values: values
    	self subclassResponsibility.
  

As it is possible to see in lines 9, 13 or 23 of the above code, the framework itself also profits from the fact that the data structures that are being passed are ensembles. By having ensembles as the main element being passed around, it is possible to have implicit parallel behavior, which is the key of the MapReduce approach. Evidently, in this case we are discussing a very limited version of MapReduce meant to be used on a single computer, but it is still useful to show how the implicit parallelism in Sly3 works.

Conclusions

In the spectrum of language abstractions for dealing with parallelism and concurrency, Sly3 is a language that has opted for a conservative style, in the sense that it is a specific element of the language (an ensemble) the one that is subject of parallelism. On the other hand, the stress has been put on giving a set of tools to programmers, enabling them to combine these tools. For customized strategies, it is the impression of the author of this article that the level of granularity is too coarse-grained. Although it is conceivable to extend the set of adverbs and gerunds by extending the hierarchy aforementioned, this implies to understand the Sly3 implementation in very detail, something that we most likely do not expect from application programmers. It is possible to think of a meta-programming framework that could inject custom functionalities in the language, lowering the complexity for extending the set of primitives.

Regarding the approach to parallelism, it is implicit and synchronous. Programmers are not aware of how computations are spawned or scheduled, and the only means they have to initiate parallel computations is by using ensembles.

As regards to the syntax, Sly3 uses decorated keyword based messages to model the way the message is handled by the virtual machine. Although it is conceivable that this schema can be improved, there are some problems originated from the fact that adverbs can decorate receivers, arguments, and the overall strategy. If we add to this complexity the gerunds, it is clear that it is difficult to express these multidimensional facets using a textual syntax.

To sum up, Sly3 is a language that incorporates in its design a series of patterns to deal with parallelism, but the mechanism for extending the set of parallel primitives could be reconsidered, in order to reduce the complexity of extending Sly3. However, the MapReduce example has shown that it is possible to concisely express complex patterns of interactions in Sly3, as soon as these patterns fall within the give set of Sly3‘s primitives.

Bibliography

UA10

David Ungar and Sam S. Adams.
Harnessing emergence for manycore programming: early experience integrating ensembles, adverbs, and object-based inheritance.
In Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion, SPLASH ’10, pages 19-26, New York, NY, USA, 2010. ACM.

This year, we presented our research in the form of a Pecha Kucha talk. That means every presenter got 20 slides to present and each of the slides was shown exactly 20 seconds. That gives enough time to convey the general idea, but avoids boring the people with endless technical details.

All in all, that worked out pretty well.

My talk gave an overview of what the Parallel Programming Group is up to, on a very high level. It motivates why we are doing research in languages and language runtimes/virtual machines, and names our approaches to tackle the challenges. Well, for researchers in the field that is probably to vague, but everyone else might get just enough out of it to see in which direction we are going.

The RoarVM supports the parallel execution of Smalltalk programs on x86 compatible multicore systems and Tilera TILE64-based manycore systems. It is tested with standard Squeak 4.1 closure-enabled images, and with a stripped down version of a MVC-based Squeak 3.7 image. Support for Pharo 1.2 is currently limited to 1 core, but we are working on it.

A small teaser:
1 core   66286897 bytecodes/sec;  2910474 sends/sec
8 cores 470588235 bytecodes/sec; 19825677 sends/sec

RoarVM is based on the work of David Ungar and Sam S. Adams at IBM Research. The port to x86 multicore systems was done by me. They open-sourced their VM, formerly know as Renaissance VM (RVM), under the Eclipse Public License. Official announcement of the IBM source code release: http://soft.vub.ac.be/~smarr/rvm-open-source-release/

The source code of the RoarVM has been released as open source to enable the Smalltalk community to evaluate the ideas and possibly integrate them into existing systems. So, the RoarVM is meant to experiment with Smalltalk systems on multi- and manycore machines.

The open source project, and downloads can also be found on GitHub:

http://github.com/smarr/RoarVM
http://github.com/smarr/RoarVM/downloads

For more detailed information, please refer to the README file.
Instructions to compile the RoarVM on Linux and OS X can be found in the INSTALL file.
Windows is currently not supported, however, there are good chances that it
will work with cygwin or pthreads for win32, but that has not be verified in
anyway. If you feel brave, please give it a shot and report back.

If the community does not object, we would like to occupy the
vm-dev@lists.squeakfoundation.org mailinglist for related discussions. So, if
you run into any trouble while experimenting with the RoarVM, do not hesitate
to report any problems and ask any questions.

You can also follow us on Twitter @roarvm.

The Renaissance VM has been open sourced. The official contribution of IBM Research to the open source community can be found here: The Renaissance Virtual Machine: Open Source Release Announcement.

The code is already posted to GitHub and somewhat extended to make it actually useful. Please feel free to head over to http://github.com/smarr/RoarVM, play with the code, try the VM with your image, and report back.

The official announcement will be send out in the next couple of days, but any feedback we could get before hand would allow to fix issues before the community gets started with the VM.

Tuesday – Evolution, Onward!, FPGAs, and the Hera-JVM

On Tuesday the main conference started with its keynotes and research tracks.

The keynote of Stephanie Forrest was an interesting introduction to how evolutionary approaches could be used in software development. One goal they are currently pursuing is fixing of certain types of bugs by reordering, deleting, and/or copying of parts in an AST. Well, that can not fix every bug, but might be interesting for many typical problems. Certainly the type of bugs I run into most frequently…

Onward! started with three interesting talks in the area of languages. The first on Registration-Based Language Abstractions presented an IDE approach to bringing high-level constructs to existing code-bases. You basically have an “imaginary” view only present in your IDE of what the low-level implementation details actually are meant to represent. Examples were simple standard Java for-loops using C-like notation getting replaced by for-each loops, or even whole class bodies getting simplified by abstracting from typical getter/setter patterns, or even delegation patterns. Neat!

Toon’s talk on Pinocchio: Bringing Reflection to Life with First-Class Interpreters advocated fully reflective systems that make it easy to build bug-specific debuggers. Thats a great idea, unfortunately not feasible in VMs which are not build in a meta-circular fully reflective way, I think. We definitely need something more sophisticated for RoarVM than printf…

The last talk on this track was on Concurrency by Modularity: Design Patterns, A Case in Point. Well, on the one hand I agree, there are certain design patterns from the gang of four which can be parallelized, however, that does not solve the problem of share state… The point that increased modularity will increase you degree of possible parallelism might be appealing but it is only a correlation and not a strict causal relationship.

The presentations after lunch were addressing performance from the angle of FPGAs. The presentation on Lime: a Java-Cpmpatible and Synthesizable Language for Heterogenous Architectures made a case for object-oriented programming for FPGAs. The idea is to have a superset of Java, with a few additional keywords, that is than mappable to hardware. As far as I understood, Lime is basically a stream-based language and thus favors data-oriented programming. The second talk was titled From OO to FPGA: Fitting Round Objects into Square Hardware? Interesting for me were the challenges they had to overcome to actually implement an OO language on top of an FPGA. The problem is mainly today’s available tool chains, that usually support only a very restricted subset of C.

The second session in the afternoon included the most related talk to my own research, a presentation on a port of the JikesRVM to the Cell processor: Hera-JVM: A Runtime System for Heterogeneous Multi-Core Architectures. The heterogenous instruction set was not the biggest challenge here, but the restricted local memory of the SPEs required them to pull a few tricks. Not only the size, but also the non-shared memory approach gave problems. To support the full semantics of the JMM, they had to implement a coherence mechanism in software. Have seen something similar for the read-mostly heap in our RoarVM before

Afterwards, I arranged the necessary details for our Birds of a Feather meeting on Non-deterministic Programming.

Wednesday – Assertions tested by the GC, Dynamic Parallelization

On the OOPSLA track, I followed a talk on What Can the GC Compute Efficiently? This was an interesting talk, since I haven’t heard about anything similar before. The general idea is, that the GC supports an assertion system which allows to express a certain number of directly determinable properties. While the GC is doing its normal job, it can also check those assertions and verifies the described invariants almost for free. Again, neat Of course, the system has certain restrictions and the assertion language basically needs to ensure that the assertions can be checked in a single pass.

In the second session, Charlotte gave her talk on Dynamic Parallelization of Recursive Code. Have seen a presentation on her idea before, so most of the time I was think how could that be made fast. Would be great if she would purse the same idea in a Tracing JIT setting *sigh* Just for the fun of it, I suppose I bet there could be something in the idea of moving all the tracing, branch-prediction and speculative execution out of the CPU into the software. If they are really going for dump and small cores in the many-many-core world, we could squeeze at least some speedup out of those sequential algorithms. See the workshop paper by András Vajda and Per Stenström. Cool stuff, all that automatic parallelization non-sense with out the speculating part won’t work anyway

Thursday – Search without Objectives,

The day started with a very interesting keynote. The take-away point is, if your goal is not reachable in a number of steps you can already predetermine, i.e., if you don’t have all the basic ingredients, than the typical goal-driven search approaches do not deliver good results. Instead of using a metric of whether your search brings you closer to your goal, you should us a metric that rewards novelty, interestingness, or just the differentness from the points you have reached in your search before. Searching with such a metric leads much more probable and typically a lot faster towards your initial goal. Kenneth Stanley present a number of very convincing arguments, but in the end he had also to admit that this approach is somehow constraint in its applicability by the rules of society. But at least we should try. So, on to something new!

The second keynote of the day was a bit too, ehm, applied? Well, it was certainly interesting to see what the influence of the F# team was on the .NET platform, but well, there was not really meat in that talk. From a theoretic perspective the CIL of .NET appeals to me much more than the JVM Bytecode set, but well, he was not talking about such low-level questions…

Afterwards, I followed the last OOPSLA session. Mainly out of curiosity what ownership types are all about. Now I have seen three talks, and can be reassured, they are not relevant for my VM design. Good. Well, the point is, such a type system just does not fit with a VM. Dynamic languages can not be sensibly compiled to such a type system, I think. Thats more a gut feeling than a great insight, but I don’t see how they match.

The last session of SPLASH for me was the short paper session of the Onward! track. It started very interesting with an experiment on how performance metrics can be turned to sound: Sonifying Performance Data to Facilitate Tuning of Complex Systems. I should try that for our VM, any approach is better than the one I use now… no at all *sigh* Well, our boids simulation already indicated a bug once, but well, if it is not used… Anyway, the talk was interesting, and the results could inspire further experiments.

The last talk was David’s: Harnessing Emergency for Manycore Programming: Early Experience Integrating Ensembles, Adverbs, and Object-based Inheritance. What should I say, of course David mentioned the RoarVM Thats great. But if it comes to the language, there are still a lot of open questions. Interestingly, David really managed to get the people thinking about the problem he presented. It was a small little puzzle of language design, something that seemed to appeal to the audience. He got some suggestions, but well, no ground breaking new idea as far as I could see. Hope they will follow up on it offline.

And that was SPLASH’10. Should have went to Lake Tahoe, saw some nice pictures of the nature, but hadn’t had the time Conclusion, Reno was just the right place to focus on work…

After one year, I am back looking at that paper, and it still looks like a great model. Think, I will incorporate it into my manycore VM now

Abstract

In this position paper we propose to extend an existing delegation-based machine model with concurrency primitives. The original machine model which is built on the concepts of objects, messages, and delegation, provides support for languages enabling multi-dimensional separation of concerns (MDSOC). We propose to extend this model with an actor-based concurrency model, allowing for both true parallelism as well as lightweight concurrency primitives such as coroutines. In order to demonstrate its expressiveness, we informally describe how three high-level languages supporting different concurrency models can be mapped onto our extended machine model. We also provide an outlook on the extended model’s potential to support concurrency-related MDSOC features.

• Towards an Actor-based Concurrent Machine Model, Hans Schippers, Tom Van Cutsem, Stefan Marr, Michael Haupt, Robert Hirschfeld, Proceedings of the fourth workshop on the Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and Systems (ICOOOLPS), New York, NY, USA, ACM (2009), p. 4–9.
• Paper: PDF
  ©ACM, 2009. This is the author’s version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in ICOOOLPS’09 July 6, 2009, Genova, Italy. http://doi.acm.org/10.1145/1565824.1565825
• BibTex: BibSonomy