Growing
the Ruby Interpreter
Koichi Sasada<ko1@heroku.com>

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Today’s talk
• Ruby 2.1 and Ruby 2.2• How to grow up the Ruby interpreter?
• Evaluator• Threading• Object management / Garbage collection

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Koichi Sasada as a Japanese
4 hourstransit

12 hours

15 hours[HOME]
8/25 5:00am (BRT)[HOTEL]
8/26 7:30pm (BRT)[TOTAL]38.5 hours

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Koichi Sasada as a Programmer• CRuby/MRI committer• Core components developer• Virtual machine (YARV) since 2004/1/1• Rewrote Threads, GC, and so on• Matz team at Heroku, Inc.
• Director of Ruby Association

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Advertisement• Foundation to encourage Ruby dev. andcommunities• Activities• Ruby programmer certification program• http://www.ruby.or.jp/en/certification/examination/ in English• Grant project. Submit your proposal now!
• 3 projects. About 5,000 USD per project (deadline: 3rd ,Oct)• http://www.ruby.or.jp/en/news/20140805.html• Ruby Prize• Maintenance of Ruby (Cruby) interpreter• Events, especially RubyWorld Conference• Donation for Ruby developments and communities
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Advertisement

Heroku, Inc. http://www.heroku.com

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Advertisement

Heroku, Inc. http://www.heroku.com
Ask Nando Vieira for more details

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014• Heroku supports OSSs
• Many talents for Ruby, and also other languages• Heroku employs 3 Ruby interpreter coredevelopers• Matz• Nobu• Ko1 (me)• We name our group “Matz team”

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Matz
Famous title collector• He has so many (job) title• Chairman - Ruby Association• Fellow - NaCl
• Chief architect, Ruby - Heroku• Research institute fellow – Rakuten• Chairman – NPO mruby Forum• Senior researcher – Kadokawa Ascii Research Lab• Visiting professor – Shimane University• Honorable citizen (living) – Matsue city
• Honorable member – Nihon Ruby no Kai• …

• This margin is too narrow to contain
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Nobu
Patch monster• Great patch creator

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Nobu isGreat Patch Monster
COMMITRATIOIN LAST 5 YEARS
davidflanagan
technorama
a_matsuda
iwamatsu
murakenheadiusgotoken
okkez
eban
evan
kanemoto
tmm1
seki
arton
hsbt
jeg2
luislavena
takano32
duerst
kouji
suke
keiju
azav
wanabengoto
eregonnagai
xibbarshirosaki
charliesome
ryan
sorah
tarui
ayumin
nahi
ktsj
glass
nari
shyouheiemboss
mrkn
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
kou
0%
0%
0%
0%
yugui
0%
0%
nagachika
0%
1%
1%
shugo
1%
1%
knu
1%
nobu
1%
tadf
1%
29%
mame
2%
marcandre
2%
matz
2%
tenderlove
2%
zzak
2%
kazu
2%
2%
kosaki3%drbrain

3%

ko1
4%usa
naruse
4% 8%

svn
9%

akr
12%

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Ko1
EDD developer
EurukoCommit number of ko1 (last 3 years)
2013
RubyKaigi
2013
RubyConf
RubyConf
2012
2013

25

20

15

Ruby 2.0
105

EDD: Event Driven Development
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 20142013/11/8

2013/9/8

2013/7/8

2013/5/8

2013/3/8

2013/1/8

2012/11/8

2012/9/8

2012/7/8

2012/5/8

2012/3/8

2012/1/8

2011/11/8

2011/9/8

2011/7/8

2011/5/8

2011/3/8

2011/1/8

2010/11/8

0“Mission of Matz team”

Improve quality ofnext version of CRuby
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

“Mission of Matz team”• Improve quality of next version of CRuby• Matz decides a spec finally• Nobu fixed huge number of bugs
• Ko1 improves the performance• Next version of CRuby is “Ruby 2.2.0”

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

http://www.flickr.com/photos/loginesta/5266114104

Ruby 2.1
Current stable
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Ruby 2.1
a bit old Ruby
• Ruby 2.1.0 was released at 2013/12/25• New features• Performance improvements• Ruby 2.1.1 was released at 2014/02/24• Includes many bug fixes found after 2.1.0 release• Introduce a new GC tuning parameter to change
generational GC behavior (introduce it later)• Ruby 2.1.2 was released at 2014/05/09• Solves critical bugs (OpenSSL and so on)

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Ruby 2.1 New syntax• New syntaxes• Required keyword
parameter• Rational number literal• Complex number literal• `def’ returns symbol ofmethod namehttp://www.flickr.com/photos/rooreynolds/4133549889

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Ruby 2.1 Runtime new features• String#scrub• Process.clock_gettime• Binding#local_variable_get/set• Bignum now uses GMP (if available)• Extending ObjectSpace

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Performance improvements• Optimize “string literal”.freeze• Sophisticated inline method cache• Introducing Generational GC: RGenGC

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Accumulated execution time (sec)

RGenGC
Performance evaluation (RDoc)
14
12
10
8
6

About x15 speedup!

4

20
Total mark time (ms)w/o RGenGC

Total sweep time (sec)
RGenGC* Disabled lazy sweep to measure correctly.

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

http://www.flickr.com/photos/adafruit/8483990604

Ruby 2.2
Next version
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Ruby 2.2 schedule
2013/12Ruby 2.1.0

2014/12/25

We arehere!

RubyConf
Brasil8/28, 29

Ruby 2.2.0

RubyKaigi
9/18, 19, 20

RubyConf
11/17, 18, 19

Events are important for
EDD (Event Driven Development) Developers
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Ruby 2.2 (rough) schedule
2013/12Ruby 2.1.0

2014/12/25
Ruby 2.2.0

We arehere!

Sep/2014
Preview 1
Big feature freeze

Sep/2014
Dev. Meeting
Feature proposal

Bug fix only

Nov/2014
Preview2
Feature freeze

Critical Bug fix only

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Dec/2014
Releasecandidate2.2 big features (planned)• New syntax: not available now• New method: no notable methods availablenow• Libraries:• Minitest and test/unit will be removed (provided bybundled gem)

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

2.2 internal changes• Internal• C APIs• Hide internal structures for Hash, Struct and so on• Remove obsolete APIs

• GC
• Symbol GC (merged recently)• More ages strategy to reduce too-fast-promotion• Incremental GC to reduce major GC pause time

• VM
• More sophisticated method cache
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Ruby 2.2 internals
Symbol GC
1_000_000.times{|i| i.to_s.to_sym}
p Symbol.all_symbols.size# Ruby 2.1#=> 1,002,376# Ruby 2.2 (dev)#=> 25,412
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

http://www.flickr.com/photos/donkeyhotey/8422065722

NOTE: Drink a drop of water

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Growing up
the Ruby Interpreter
How do we grow up the Ruby interpreter?

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Software consists ofmany components
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Ruby’s components for users
Ruby (Rails) app

i gigantum umeris insidentes
Standing on the shoulders of giants

So many gems
such as Ruby on Rails (ActiveSupport, …) and so on.
RubyGems/Bundler

Ruby interpreter
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Ruby’s components
from core developer’s perspective
Ruby
scriptBundledLibraries

Gem
Libraries

Embeddedclasses and methods(Array, String, …)

Parse

CompileThreading

Evaluator

Ruby
BytecodeInterpret on RubyVM
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Objectmanagement(GC)My contributions• Improve the performance for• Evaluator (10 years)• Thread management (10 years)• Memory management (recent years)

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

History of Ruby interpreter
1993 2/24
Birth of Ruby
(in Matz’ computer)

1996/12Ruby 1.0

1995/12Ruby 0.95

1999/12Ruby 1.4

1998/12Ruby 1.2

2000/6
Ruby 1.6

2003/8Ruby 1.8
2009/1
Ruby 1.9.0

2013/2
Ruby 2.0
2013/12Ruby 2.1.0

1st release2004/1YARV development
2013/3RGenGC
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Grow up Ruby interpreter bymodification of core components

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Evaluator
Ruby
scriptBundledLibraries

Gem
Libraries

Embeddedclasses and methods(Array, String, …)

Parse

CompileThreading

Evaluator

Ruby
BytecodeInterpret on RubyVM
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Objectmanagement(GC)Evaluator• Named YARV: Yet another RubyVM• Start until 10 years ago (2004/01/01)• Simple stack machine architecture• Execute each bytecode instructions one by one• Apply many known optimization techniques

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Evaluator
Compile Ruby to AST
Abstract Syntax Tree

Ruby Program
Parse

a=b+c

a=
MethodDispatch(:+)

bGrowing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014c

Evaluator
Compile AST to Bytecode
Abstract Syntax TreeVM Instructionsa=getlocalgetlocalsend
setlocalMethodDispatch(:+)

bcTree databc+aSequential data

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Evaluator
Execution as stack machine
Ruby Program

a=b+cCompileYARV Instructions

getlocalgetlocalsend
setlocal

b
c
+
a

a
b+c
b

c

c

b+c
b
VM Stack

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Evaluator
Optimizations• Apply many techniques to improve performance• Peephole optimizations• Specialized instructions• Stack frame layout• Efficient exception handling• Efficient block representation• Direct threading• Stack caching• Instructions and operands unifications•…
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Evaluator
Optimizations: Basic concept• Analysis usage
And optimize for frequent cases• Example: Exception handling• Exceptions occur *EXCEPTIONAL* so
optimize for no-exception control flow

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Performance evaluationcompare with Ruby 1.8
Higher is good

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Main components• Evaluator• Thread management• Memory management

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Threading
Ruby
scriptBundledLibraries

Gem
Libraries

Embeddedclasses and methods(Array, String, …)

Parse

CompileThreading

Evaluator

Ruby
BytecodeInterpret on RubyVM
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Objectmanagement(GC)Threading• Using native threads for each Ruby threads• Parallel ruby execution is prohibited by GVL• You can free GVL if you write a code carefully in C level
and run it in parallel

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Threading
Ruby 1.8 and before
One OS (native) thread manages all Ruby threads
This technique is a.k.a. Green Thread
CPU 1

Thread 1

Thread 2

Thread 1
OS Thread 1

CPU 2

IDLE

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Threading
Layered view
Ruby
RT

Native Thread
System S/W

・・・

RT

RT

・・・

NT

Thread Scheduler

S/W
H/W
Processor(s)
PE

PE

・・・

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

PE

Threading
Ruby 1.9 and later
Native threads with Giant VM Lock
Thread 1

Thread 1
CPU 1

OS Thread 1

Lock
Thread 2

Lock
OS Thread 2

CPU 2

IDLE
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Threading
Layered view
Ruby

Native Thread
System S/W

RT

RT

NT

NT

・・・

・・・

RT

NT

Thread Scheduler

S/W
H/W
Processor(s)
PE

PE

・・・

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

PE

Threading
Why not green threads?
• Advantage of green threads• Lightweight creation

We don’t need to makethreads frequently.
(and we also have Fiber)• Disadvantage of green threads• Slow context switching (under portable way)
• Need to take care for blocking methods• Such as network read/write• Difficult to collaborate with other C libraries using threads

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Threading
Why GVL?
• To protect Ruby users from nightmare debugging• Shared parallel threading can make non-deterministic
bugs which is too hard to debug• “Thread programming is too difficult for human being”• Disadvantage• CRITICAL ISSUE: No parallel programming in Ruby
• Need another programming model for parallel• Current *SHARED EVERYTHING* model is not match• Correct isolation level for each parallel execution units
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Threading
How to make parallel ruby program?
• Now:• Use parallel threads provided by JRuby/Rubinius• If you think you can make correct thread programs• Use process (for example, w/ parallel gem, w/ dRuby)• Future:• Introduce smart conventions to avoid threading bugs
• Matz likes Actor model (Erlang)• Introduce limited shared memory model• Introduce smart debugging feature• Detecting bugs, avoid nondeterministic behaviors, …
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Object management (GC)
Ruby
scriptBundledLibraries

Gem
Libraries

Embeddedclasses and methods(Array, String, …)

Parse

CompileThreading

Evaluator

Ruby
BytecodeInterpret on RubyVM
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Objectmanagement(GC)Object and memory management• “Object.new” allocate a new object• “foo” (string literal) also allocate a new object• Everything are objects in Ruby!

• We don’t need to “de-allocate” objects manually

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Garbage collection
The automatic memory management

http://www.flickr.com/photos/circasassy/6817999189/

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Automatic memory management
Basic concept• Garbage collector recycled “unused” objects
automaticallyGrowing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Mark & Sweep algorithm
Root objects
traverse
freemarkedtraverse

traverse

markedtraverse

markedmarkedtraversefree

1. Mark reachable
objects from rootobjects
2. Sweep unmarked
objects (collection
and de-allocation)

Collect unreachable
objects

markedfree
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

RGenGC: Restricted
Generational GC

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Generational GC (GenGC) from
Ruby 2.1• Weak generational hypothesis:“Most objects die young”

http://www.flickr.com/photos/ell-r-brown/5026593710→ Concentrate reclamation effort
only on the young objects
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Generational hypothesis
Object lifetime in RDoc
(How many GCs surviving?)

Percentage of dead object#

100

90

95% of objects dead by the first GC

80
70
60
50
40
30
20
10
0
0

3

6

9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 63 66 69 72 75 78 81 84 87 90 93 96 99 102

Lifetime (Survibing GC count)
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Generational GC (GenGC)• Separate young generation and old generation• Create objects as young generation• Promote to old generation after surviving n-th GC• In CRuby, n == 1 (after 1 GC, objects become old)
• n == 2 or 3 from Ruby 2.2• Usually, GC on young space (minor GC)• GC on both spaces if no memory (major/full GC)

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

GenGC [Minor M&S GC] (1/2)
1st MinorGC• Mark reachable objects fromroot objects.

Root objects
traverse
new/
free

new
old
traverse

traverse

new/
free

collectnewoldtraverse
new
old

new
old
traverse
newold• Mark and promote to oldgeneration• Stop traversing after old
objects→ Reduce mark overhead• Sweep not (marked or old)
objects• Can’t collect Some
unreachable objects
Don’t collect old object
•
old/
free

even
if it theis unreachable.
Growing
Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

GenGC [Minor M&S GC] (2/2)
2nd MinorGC• Mark reachable objects fromroot objects.

Root objects
traverse
new/
free

old
ignoreignorenew/freecollectoldignoreold

oldignoreold• Mark and promote to oldgeneration• Stop traversing after old
objects→ Reduce mark overhead• Sweep not (marked or old)
objects• Can’t collect Some
unreachable objects
Don’t collect old object
•
old/
free

even
if it theis unreachable.
Growing
Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

GenGC [Major M&S GC]• Normal M&S• Mark reachable objects fromroot objects

Root objects
traverse

new/
free

new
traverse

traverse

new/
free

• Mark and promote to old gen• Sweep unmarked objects

collectoldtraverse

oldnew• Sweep all unreachable(unused) objects

traverse
old

old/
free
collect
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Accumulated execution time (sec)

RGenGC
Performance evaluation (RDoc)
14
12
10
8
6

About x15 speedup!

4

20
Total mark time (ms)w/o RGenGC

Total sweep time (sec)
RGenGC* Disabled lazy sweep to measure correctly.

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

RGenGC
Performance evaluation (RDoc)
Total execution time (sec)

140
120

16.04393815
4.946003494

100
80
60
40

103.7627479

102.3799865

w/o RGenGC

RGenGC20
0other than GC

GC* 12% improvements compare with w/ and w/o RGenGC
Growing the Ruby interpreter, Koichi Sasada,* Disabledlazy sweep
measurecorrectly.
RubyConfto
Brasil2014

RincGC:
Restricted incremental GC

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

RincGC
Background and motivation• Ruby 2.1 had introduced generational GC• Short marking time on minor GC• Improve application throughput• Still long pause time on major GC• Long pause time affects user response time

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Proposal:
RincGC: Incremental GC for major GC• Introducing incremental GC to reduce pause time
• Can combine with Generational GC
Generational Incremental Gen+Inc GC
GC
GC
Throughput
High
Low (a bit
High
slow)
Pause time
Long
Short
Short
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

RincGC: Base idea
Incremental GC algorithm• Move forward GC processes incrementally• Mark slots incrementally• Sweep slots incrementally• Incremental marking in 3 phase• (1) Mark roots (pause)• (2) Mark objects reachable from roots (incremental)• (3) Mark roots again, and mark remembered objects (pause)• Mark objects with three state (white/grey/black)• White: Untouched objects• Grey: Marked, and prepare to mark directly reachable objects• Black: Marked, and all directly reachable objects are marked• Use write barriers to avoid marking miss from marked objects to live
objects• Detect new reference from black objects to white objects• Remember such source
blacktheobjects(markedat above
Growing
Ruby interpreter,
Koichi
Sasada, (3))
RubyConf Brasil 2014

RincGC:
Incremental GC for CRuby/MRI• Incremental marking• (1) mark roots (gc_mark_roots())• (2) Do incremental mark at rb_newobj_of()• (3) Make sure write barrier with WB-protected objects• (4) Take care of WB-unprotected objects (MRI specific)• Incremental sweeping• Modify current lazy sweep implementation

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

RincGC:
Incremental marking• (1) mark roots (gc_mark_roots())• Push all root objects onto “mark_stack”• (2) Do incremental mark at rb_newobj_of()• Fall back incremental marking process periodically• Consume (pop) some objects from “mark_stack” and makeforward incremental marking• (3) Make sure write barrier with WB-protected objects• Mark and push pointed object onto “mark_stack”• (4) Take care of WB-unprotected objects (MRI specific)• After incremental marking (“mark_stack” is empty), re-scan
all roots and all living non-WB-protected objects• WB-unprotected objects are represented by bitmap(WB_UNPROTECTED_BITS)
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

RincGC:
DiagramDirect transition

State: marking

garbage_collect()
if (nopages)

Via mutator(clear doing flag)

State: sweeping

marks_start()

sweep_start()

newobj()if (incremental_marking)doing: truemarks_continue()marks_step()

if (sweep_pages)

sweep_step()doing: true

sweep_continue()marks_finish()
if (root scan detect unmarked objects)

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

sweep_finish()State: none

Growing up
the Ruby Interpreter
How do we grow up the Ruby interpreter?

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

DO EVERYTHING!
NO SILVER BULLET!
Ruby
scriptBundledLibraries

Gem
Libraries

Embeddedclasses and methods(Array, String, …)

Parse

CompileThreading

Evaluator

Ruby
BytecodeInterpret on RubyVM
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Objectmanagement(GC)DO EVERYTHING!
NO SILVER BULLET!
Loop do• Survey techniques• Implement techniques• Invent new techniques• Evaluate techniques

end # endlessGrowing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

DO EVERYTHING!
NO SILVER BULLET!
We did.
We are doing.
We will do!!

Only continuous effort
improves software quality.
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Future work: Many many many!!
• Evaluator• JIT compilation• More drastic optimizations• Threading• Parallel execution model (not a threading?)• Object management and GC• Compaction GC• Lightweight object allocation• CoW friendly memory management• And more
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Summary• Ruby 2.1 and Ruby 2.2• How to grow up the Ruby interpreter?
• Evaluator• Threading• Object management / Garbage collection

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Summary• Ruby 2.1 and Ruby 2.2• How to grow up the Ruby interpreter?
My answers is:#=> Continue software development(with love?)
Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014

Thank you for your attention

Koichi Sasada<ko1@heroku.com>

Growing the Ruby interpreter, Koichi Sasada,
RubyConf Brasil 2014