Runtime Devirtualization

[Robin Holmes]

If you have or are involved with building a VM that can do proper
inlining, then see this new method of speeding up some kinds of code
constructs when programming with objects.

The concept is like bulk runtime object devirtualization where the
devirtualization is for inlining both virtual method calls and field
references. IT works with attributes applied to fields and methods
similar to something like cdecl. For things like compilers, VST
plugins, some RegeX, SQL etc there is scope for massive speedup
enhancement.

See http://pacificv.prophp.us/rod.php for more details.

 

[Joshua Cranmer]

See http://pacificv.prophp.us/rod.php for more details.

Well, besides your blatant multiposting, I just want to point out:

Copyright(c) 2009/2010 Robin Holmes. All rights reserved.
This is a public domain specification.

Which is it? The two mean contradictory things...

 

[Roedy Green]

If you have or are involved with building a VM that can do proper
inlining, then see this new method of speeding up some kinds of code
constructs when programming with objects.

The concept is like bulk runtime object devirtualization where the
devirtualization is for inlining both virtual method calls and field
references. IT works with attributes applied to fields and methods
similar to something like cdecl. For things like compilers, VST
plugins, some RegeX, SQL etc there is scope for massive speedup
enhancement.

See http://pacificv.prophp.us/rod.php for more details.

how is this different from what Hotspot does?

 

[Lew]

how is this different from what Hotspot does?

HotSpot doesn't use the meaningless term "devirtualization", it is already
included with the JVM, it has a team of engineers and computer scientists
constantly working to improve it, it incorporates the hottest academic
research in its underpinnings, it integrates well with other advanced JVM
features like the debugger interface, it actually works ...

 

[Robin Holmes]

You are misreading the word devirtualization. Hotspot devirtualization
is "runtime type devirtualization" based on the known "type" of an
object in the bytecode, possibly and normally before that object is
created.

Runtime Object devirtualization works with already allocated objects,
and branches down into child objects and fields that are already
allocated and provides a mechanism to recompile the devirt function
should one of those sub-devirt functions change.

Please this post is for people who are understanding VM and JIT and
VTable etc... If you dont understand it then dont reply.

Hotspot is not the topic here. This is a new theory for mass speed up
of some kinds of code made with virtual object programming. Again,
please only reply if you understand it.

 

[Robin Holmes]

If you read here below you can see the difference bettwen ROD and RTD.
RTD is what Hotspot does and is quite static. ROD is a new design that
works with already allocated objects(EMPHASIS ON PLURAL OBJECTS).

When a virtual function is called it is passed an object instance
(called this) as the first parameter. The passed object is the current
context for the virtual function that executes. When the function must
be rebuilt, normally because one of the devirt field objects it uses
has changed, then the code will pass the current “this” parameter to
the JIT and tell it to rebuild the function with devirtualization.
Because the JIT knows the “actual” this object that will be used by
the specific function call, it can track all references to the object
and the type of the object. So when the bytecode specifies to do a
virtual function call on the passed object, it can then inline the
virtual function call instead, and it is this inlining that causes the
removal of lots of redundant instructions. In .NET and Mono an
instruction like LDARG.0 applies. The JIT will see this instruction
and then check if it knows the current value that will be used in
addition to the type of the argument. If it knows the value, then it
can inline virtual calls, and it can also put direct memory references
into the output machine code. For example, a reference to an integer
or float value inside the object can be referenced by its allocated
address at runtime, which can save some memory access instructions.

THIS TEXT QUOTED FROM ROD SPECIFICATION

 

[Robin Holmes]

HERE IS MORE QUOTED TEXT FROM ROD ILLUSTRATING HOW THE
DEVIRTUALIZATION IS WORKING "PER-INSTANCE" AND NOT "PER-TYPE". THUS IT
YIELDS A VERY LARGE INLINING CONTEXT WHICH EXPANDS TO INCLUDE OTHER
ALREADY ALLOCATED INSTANCES. THERE IS NOTHING PREVENTING EXISTING RTD
(Runtime Type Devirtualization) BEING USED AT THE SAME TIME AS ROD,
BUT ROD(Runtime Object devirtualization) IS NOT RTD.

As the JIT is building the function it might come across instructions
that load fields and global variables from allocated objects that it
knows about. If the fields that it finds in objects that are already
allocated(for example the this parameter), are marked devirt, then it
can load, track and devirtualize those objects as well. This is
recursive up until there are no more devirt fields or objects to be
found or until the inlining has gone to deep. Devirtualization
functions are special and the JIT allows the inlining to go very deep
by default.

Note that when a function is to big to be inlined but it is virtual
and would otherwise be inlinable in a devirtualization context, then
the function call can be like calling an instance method of an object,
which is faster than calling it like a virtual function.

 

[Lew]

Note that when a function is to big to be inlined but it is virtual
and would otherwise be inlinable in a devirtualization context, then
the function call can be like calling an instance method of an object,
which is faster than calling it like a virtual function.

You know, you like to say that this is different from what HotSpot does, but
that difference is unclear from your vague posts. In fact, your descriptions
of your whiz-bang, for-geniuses-only, best-thing-since-sliced-bread theory
sounds exactly like HotSpot. How about you answer Roedy's and my question and
explain better how they differ, hm?

 

[Joshua Cranmer]

HERE IS MORE QUOTED TEXT FROM ROD ILLUSTRATING HOW THE
DEVIRTUALIZATION IS WORKING "PER-INSTANCE" AND NOT "PER-TYPE". THUS IT
YIELDS A VERY LARGE INLINING CONTEXT WHICH EXPANDS TO INCLUDE OTHER
ALREADY ALLOCATED INSTANCES. THERE IS NOTHING PREVENTING EXISTING RTD
(Runtime Type Devirtualization) BEING USED AT THE SAME TIME AS ROD,
BUT ROD(Runtime Object devirtualization) IS NOT RTD.

Please stop shouting. It makes you come across as a whiny 10-year old.
Possibly younger.

As the JIT is building the function it might come across instructions
that load fields and global variables from allocated objects that it
knows about. If the fields that it finds in objects that are already
allocated(for example the this parameter), are marked devirt, then it
can load, track and devirtualize those objects as well. This is
recursive up until there are no more devirt fields or objects to be
found or until the inlining has gone to deep. Devirtualization
functions are special and the JIT allows the inlining to go very deep
by default.

From this paragraph, it sounds like your "devirtualization" is merely a
technique that will take a getfield Foo.bar and transform it to a "load
this physical address." Until you start talking about functions again
and then any coherent thread of logic is simply lost.

Perhaps it may just be that you're referring to features in VM
environments other than Java. As you are posting to a Java newsgroup, it
would behoove you to use the Java VM as your primary context for a VM
and mention other features only in reference comparison.