Seven new VMs, all in a row

[Avi Bryant]

What about systems like Rails where members are added to the class
definition at runtime from a database definition? ( I assume that's how
it works. )

If you're talking about methods, that's no problem at all - like Ruby,
Smalltalk makes no distinction between compile-time and runtime (in
fact, Smalltalk environments don't even make a distinction between
edit-time and runtime), so adding (or removing, or modifying) methods
at "runtime" is the usual case.

If you're talking about instance variables: when you add a new instance
variable to a class, the system walks through all of the old instances
of that class and makes a new copy with space allocated for the new
inst var. The next step, which requires VM support, is to do an atomic
swap of all of the old instances for all of the new instances (some
Smalltalks can do this faster than others, but in the worst case it
requires a full garbage collection).

My guess is that for almost all applications, the occasional added cost
when adding inst vars would be more than made up for by the increased
speed when accessing them, and the reduced memory consumption (and thus
reduced load on the GC).

Avi

 

[Avi Bryant]

The Smalltalk Ruby will still need to handle more dynamic methods of
instance variable creation:

class MyClass
def add_ivar(name)
instance_variable_set(name, nil)
end
end

What happens to instances that have already been created when a new
instance variable is seen by the compiler?

Just posted on that...

There are also issues with using more memory than necessary if the
interpreter creates every instance variable the moment it is observed by
the compiler.

Only in truly pathological cases - for normal numbers of instance
variables, the overhead of an external lookup table would be higher
than that of keeping a few unused slots in the body of the object. But
of course if the compiler saw that instances of a particular class
might have up to 50 instance variables, it could choose to implement
that class with a hashtable for variables. I'm not convinced that case
is likely enough to be worth checking and optimizing for, but who
knows.

Avi

 

[Eric Hodel]

--Apple-Mail-7--618298065
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

---------------------------
In a typical system it often turns out that the same message is sent
to instances of the
same class again and again; consider how often we use arrays of
SmallInteger or
Character or String. To improve average performance, the VM can cache
the
found method. If the same combination of the method and the receiver's
class are
found in the cache, we avoid a repeat of the full search of the
MethodDictionary
chain. See the method Interpreter > lookupInMethodCacheSel:class:
for the implementation.
VisualWorks and some other commercial Smalltalks use inline cacheing,
whereby the
cached target and some checking information is included inline with
the dynamically
translated methods. Although more efficient, it is more complex and
has strong
interactions with the details of the cpu instruction and data caches.
---------------------------

So message dispatching with squeak is not much more efficent then what
i expect from YARV, a simple bytecode dispatcher with dynamic method
lookup tables and a small lookup cache.

You missed the second to last sentence, "... the cached target and some
checking information is included inline with the dynamically translated
methods."

This can be a big boost because you don't need to look up the method or
even dispatch to it anymore, its right there where it needs to be.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-7--618298065
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iEYEARECAAYFAkJWu5QACgkQMypVHHlsnwTz0ACfbai5bqQ61K8B5DjD8ZBD15jE
TRYAoOPZdKjLMOJD3ZO7WAso9aE74a1X
=pMfW
-----END PGP SIGNATURE-----

--Apple-Mail-7--618298065--

 

[Peter Suk]

Isn't that jumping the gun just a bit? An instance variable (in Ruby)
should not exist in an object until the line that assigns/creates it
is actually executed. It's a subtle point, but it could impact some
types of reflective programming. Maybe you can mask its existence
somehow?

I've been giving this some thought. There's no reason why we can't
create ST instance vars at runtime. However, it will mean deferring
compilation. The suggestion to mask its creation is a good one from a
performance standpoint, and is certainly doable.

--Peter

 

[Peter Suk]

Avi / Peter -- thanks for providing the feedback I was looking for.
Ruby and Smalltalk do indeed sound like a good match. I remember Robert
Feldt saying a few years ago that he'd done some experiments with Ruby


Yikes! I _am_ almost completely ignorant of Smalltalk (I'm know the
basic concepts of the language, but I've never programmed in it), but
I've done some work on VMs and was genuinely interested in the answers.

Sorry, it was late at night, and that came off harsher than it should
have. It's just that I'm finding myself essentially repeating myself.
The feedback has informed my thinking and has been valuable, but I
should just tell people to go and find and read docs. I will get around
to posting them on the RubyForge site. This project is named Alumina.
Ruby is just one crystalline form of Alumina.

--Peter

 

[Lothar Scholz]

Hello Eric,

EH> On 08 Apr 2005, at 03:39, Lothar Scholz wrote:

EH> You missed the second to last sentence, "... the cached target and some
EH> checking information is included inline with the dynamically translated
EH> methods."

EH> This can be a big boost because you don't need to look up the method or
EH> even dispatch to it anymore, its right there where it needs to be.

No i did not miss it, it says that this is _NOT_ implemented in squeak,
only in the commercial VM's which i pointed out are still extrem
expensive for all of us who use it for some scripts in there
companies.

So i doubt that the Squeak Engine can do much better then YARV when
both use the same technologie (at least for message calling)

 

[Saynatkari]

Sorry, it was late at night, and that came off harsher than it should
have. It's just that I'm finding myself essentially repeating myself.
The feedback has informed my thinking and has been valuable, but I
should just tell people to go and find and read docs. I will get around
to posting them on the RubyForge site. This project is named Alumina.
Ruby is just one crystalline form of Alumina.

Thank you for that apology! Please understand you are speaking to
a group of (mostly) interested _ruby_ developers, many of whom, I,
for instance, have little or no experience with Smalltalk let alone
its VM infrastructure. You announced the topic so I think it is fair
to expect you to answer any reasonable questions from your audience
considering our collective background.

The project certainly seems interesting to me; I am somewhat reserved
about it as I would rather see as much of the available talent to go
to YARV development rather than various different projects but, then
again, there seems to be a lot of talent to go around. Just produce
code and ideas that can be reused!

Good luck!

--Peter

E

 

[linus sellberg]

The project certainly seems interesting to me; I am somewhat reserved
about it as I would rather see as much of the available talent to go
to YARV development rather than various different projects but, then
again, there seems to be a lot of talent to go around. Just produce
code and ideas that can be reused!

I don't think it is harmful in any way. Consider web frameworks.
Everyone and their mothers seem to have written one for Ruby, yet still
there are no shortage of good ones (Rails etc).

 

[Peter Suk]

Thank you for that apology! Please understand you are speaking to
a group of (mostly) interested _ruby_ developers, many of whom, I,
for instance, have little or no experience with Smalltalk let alone
its VM infrastructure. You announced the topic so I think it is fair
to expect you to answer any reasonable questions from your audience
considering our collective background.

It's fair I answer them once. However, it is amusing that I'm getting
a lot of questions in the vein of "Does Smalltalk have X?" where the
answer is really: "Funny you should mention that, but arguably
Smalltalk was X's first widespread commercial implementation.
Smalltalk has had X for (over a decade | since the beginning in 1972.)"

The project certainly seems interesting to me; I am somewhat reserved
about it as I would rather see as much of the available talent to go
to YARV development rather than various different projects but, then
again, there seems to be a lot of talent to go around. Just produce
code and ideas that can be reused!

Tell me that there will be a full-blown Object-image external to the
VM, and that all of the language-specific meta-stuff will be expressed
as first class Rite/Ruby Objects, to the point that *only* executing
bytecodes and allocating/GC-ing Objects is done by the VM, and I will
consider it! (This means that even the language itself exists only in
the image as 1st class Ruby/Rite Objects.)

--Peter

 

[Eric Hodel]

--Apple-Mail-10--611946137
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

Hello Eric,

EH> On 08 Apr 2005, at 03:39, Lothar Scholz wrote:

EH> You missed the second to last sentence, "... the cached target and
some
EH> checking information is included inline with the dynamically
translated
EH> methods."

EH> This can be a big boost because you don't need to look up the
method or
EH> even dispatch to it anymore, its right there where it needs to be.

No i did not miss it, it says that this is _NOT_ implemented in squeak,
only in the commercial VM's which i pointed out are still extrem
expensive for all of us who use it for some scripts in there
companies.

So i doubt that the Squeak Engine can do much better then YARV when
both use the same technologie (at least for message calling)

The above documentation is, in part, wrong.

ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html

See the last paragraph of Smalltalk to C Translation.

See also the last paragraph of Performance and Optimization.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-10--611946137
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iEYEARECAAYFAkJW1GQACgkQMypVHHlsnwRnrQCdGz+ye38xERfj2Z3AhQvSIu72
hX8AoMjbg20YJaeYf0r6RV3ROHkCPJmC
=YUPG
-----END PGP SIGNATURE-----

--Apple-Mail-10--611946137--

 

[Peter Suk]

It's fair I answer them once. However, it is amusing that I'm getting
a lot of questions in the vein of "Does Smalltalk have X?" where the
answer is really: "Funny you should mention that, but arguably
Smalltalk was X's first widespread commercial implementation.
Smalltalk has had X for (over a decade | since the beginning in
1972.)"

Yikes, I walked back from the car when I realized...LISP! I don't want
to argue that Smalltalk was the first widespread commericial
implementation of X, because some Lisp-er will inevitably tell me that
it was done in 1970-something, and further come back to me with photos
from an archaeological dig where paleo-lispers were doing semi
Aspect-Oriented things with "around" methods and CDR was implemented by
bashing the end off a rock with a large teak club.

Lots of neat stuff was invented awhile back, and it's only just
*really* hitting the mainstream. I'm betting on Ruby to be that horse!

--Peter

 

[Peter Suk]

I doubt it will. Even in Ruby, singleton methods are implemented with
classes under the covers.

You get the "no-prize"! Yes, this one is easy.

The fact that Ruby instance variables appear on demand, and so
references to
instance-vars cannot be directly mapped to integer offsets from a known
class definition, will likely mean some performance trade-off.

Already covered this.

--Peter

 

[Peter Suk]

Sounds fantastic, I can't wait!


Which ones do?

Avi pointed out that we don't really need them -- Smalltalk Namespaces
are really just data-structures to inform the Compiler, so we can have
Namespaces on top of any Smalltalk VM.

And what of Ruby 2.0 selector namesapces? Will they happen? And will
that
map readily to a Smalltalk VM?

Selector namespaces are hard. We can do them with compiler tricks.
We'll just have to tackle that when it comes. (And who knows, maybe
Ruby2/Rite will make the Alumina (Ruby on a Smalltalk VM) superfluous?
I hope so. I hope Ruby2/Rite will be right and we'll have a meta-level
that is freely manipulable as 1st class Objects.

--Peter

 

[Peter Suk]

Only in truly pathological cases - for normal numbers of instance
variables, the overhead of an external lookup table would be higher
than that of keeping a few unused slots in the body of the object. But
of course if the compiler saw that instances of a particular class
might have up to 50 instance variables, it could choose to implement
that class with a hashtable for variables. I'm not convinced that case
is likely enough to be worth checking and optimizing for, but who
knows.

Having your variables in a Hashtable is something I've heard of as a
means of giving Java objects more reflective & dynamic capabilities.
I've also done it as a quick and dirty way of storing Smalltalk objects
as serialized files, but still being able to read the old ones even in
after modifying their classes and adding instance variables. (Which is
not the right way to do it, but from an implementation standpoint is
slightly quicker than the right way.)

However, when you do this, you are taking a *big* performance hit. I
suspect that this is one of the reasons why the Ruby VMs and the
earlier Python VMs are so slow -- a trade-off has been made for
programmer/VM-implementor convenience. Alumina will maintain speed and
programmer convenience in exchange for VM-implementor inconvenience.

--Peter

 

[Nicholas Seckar]

Having your variables in a Hashtable is something I've heard of as a
means of giving Java objects more reflective & dynamic capabilities.

It is possible for Ruby objects to have a dynamic set of attributes. How do
you propose to handle calling instance_variable_set with random names on
objects?

Would such an operation entail resizing every instance of that object's class?
Or would a hidden subclass be created, as can be done for singleton methods?

Another option is to use slots for the attributes we know about and provide
hash based fallback for those which surprise us.

 

[Avi Bryant]

capabilities.

It is possible for Ruby objects to have a dynamic set of attributes. How do
you propose to handle calling instance_variable_set with random names on
objects?

Would such an operation entail resizing every instance of that object's class?
Or would a hidden subclass be created, as can be done for singleton methods?

Another option is to use slots for the attributes we know about and provide
hash based fallback for those which surprise us.

All of these seem pretty reasonable; I expect you'd have to work really
hard to find any program in the wild that would cause a problem for any
of those approaches. (How many times does instance_variable_set get
used with a value that is *never* referenced directly as @ivar?)

It seems like these kind of details should probably be worked out in a
private mailing list; Peter, is there one set up for Alumina? Or would
you rather get further along before opening things up to kibitzing?

Avi

 

[Peter Suk]

Replacing every existing object of a class with a new static layout
has a
very different performance profile from updating the dynamic layout of
a
single object. Silently creating a singleton class might result in
subtle
changes in Ruby semantics. Going all-dynamic layout takes a big
performance
hit.

Sounds like a performance trade-off area to me.

If you want to influence the project, join it and contribute code.
Otherwise, it's pointless to discuss this now.

--Peter