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.

1. Which
Problems
Does
a
Mul$-­‐Language
Virtual
Machine
Need
to
Solve
in
the
Mul$core/Manycore
Era?
Stefan
Marr
Ma8as
De
Wael,
Michael
Haupt,
Theo
D’Hondt
VMIL
Workshop
2011
2011-­‐10-­‐24

2. VMs
today
Performance
Memory
Management
F#
MulJ-­‐Language
Eco
System
PlaLorm
Independent
25/10/11
2

3. What
do
we
need
in
the
MulJcore/Manycore
Era?
25/10/11
3

4. Two
Dimensions
Processor
Design
Concurrency
Models
Actors
STM
DataFlow
Fork/Join
25/10/11
4

5. Processors
and
Concurrency
Models
VM?
!&'()*
!&'()*
!"#$%!&'()*
6$4&)78()&%9&4,():
!&'()*
!&'()*
!"#$%!&'()*
25/10/11
+&,%-()&. !"$*%-()&. 5
./")&0%'&'()* 1")#(2.%0#33&)&$4%0&.#5$.

6. WHAT
ARE
THE
RELEVANT
CHANGES
AT
THE
HARDWARE-­‐LEVEL?
25/10/11
6

7. Brawny
vs.
Wimpy
• High
sequenJal
• Weak
sequenJal
performance
performance
• Few
in
numbers
• High
in
numbers
25/10/11
7

8. And
everything
in-­‐between!
Brawny
Hybrid
Wimpy
IBM
Power7
Intel
MIC
Intel
i7
AMD
Fusion
Cell
B.E.
Nvidia
Fermi
25/10/11
8

9. Cores
vs.
Threads
vs.
Shared
PUs
Source:
AMD
25/10/11
9

10. Memory
and
CommunicaJon
Nehalem
Cache
Hierarchy
Four
Processor
Setup
CommunicaJon
implicit
via
memory
Source:
Intel
25/10/11
10

11. Memory
and
CommunicaJon
TILEPro64
Source:
Tilera
25/10/11
11

12. What
do
VMs
need
to
account
for?
• Appropriate
uJlizaJon
– Varying
performance
of
cores/units?
– Caches
and
simultaneous
mul,threading?
• Non-­‐uniform
memory
and
communicaJon
– Cache
hierarchies?
– Explicit
inter-­‐core
communicaJon?
25/10/11
12

13. Actors
STM
DataFlow
Fork/Join
WHAT
ARE
TYPICAL
IMPLEMENTATION
PROBLEMS
OF
CONCURRENCY
MODELS?
25/10/11
13

14. EncapsulaJon
IMPORTANT:
Messages
can
actor
BreakEncapsulation:
be
any
kind
of
object
but
have
to
be
immutable.
Scala
def
main_loop(self):
can’t
enforce
immutability
receive:
(yet)
so
this
has
to
be
by
convenJon.
(Message)
=>
Message.msg
=
"broken"
JCSP:
obj-­‐by-­‐ref,
no
warning
#
main
Kilim:
zero-­‐copy
type
system
msg
=
Message("Hello
World!")
not
“reflecJon-­‐proof”
broken
!
(msg)
Clojure:
STM
+
pure
Java
Agents
+
pure
Java
#
wait
print
msg.msg
Swing
UI:
“The
single-­‐
thread
rule”
25/10/11
14

15. Scheduling
Guarantees
Fork/Join
Actors
PrioriJzed
Tasks
work-­‐stealing
fair
scheduling
priority-­‐based
scheduling
25/10/11
15

16. Immutability
Source:
Star
Wars
Episode
V:
The
Empire
Strikes
Back.
25/10/11
16

17. Crossing
Borders
and
Language-­‐Levels
jThread.sortedSet
=
FarRefWrapper(sortSet)
e
a
jThread.sortedSet
.add(FarRefWrapper(e))
e.compareTo(*)
add(e)
//
add(fr_e)
(wrapper
semantics)
fr_e.compareTo(obj)
{
return
send_wait(e,
compareTo,
obj)
sortedSet
}
Language/ApplicaJon-­‐Level
ImplementaJon/Meta-­‐Level
25/10/11
17

18. What
do
VMs
need
to
account
for?
• Enforcing
language
semanJcs?
• Flexible
concurrent
encapsulaJon?
– What
is
the
relaJon
to
immutability?
• Enforceable
scheduling
guarantees?
• Normal
vs.
reflecJve
operaJons?
25/10/11
18

19. What
do
VMs
need
to
account
for?
Processor
Design
Concurrency
Models
Actors
STM
DataFlow
Fork/Join
25/10/11
19

20. What
do
VMs
need
to
account
for?
Processor
Design
Concurrency
Models
• Appropriate
uJlizaJon
• Flexible
concurrent
– Varying
performance?
encapsulaJon?
– Hyperthreads?
– Flexible
Immutability?
• Non-­‐uniform
memory
and
• Enforceable
scheduling
communicaJon
guarantees?
– Cache
hierarchies?
• Normal
vs.
reflecJve
– Explicit
inter-­‐core
operaJons?
communicaJon?
25/10/11
20