Prev: Inconsistent whether new browser window opens from signed applet
Next: http bug
From: Robin Holmes on 22 Jan 2010 08:58
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

From: Robin Holmes on 22 Jan 2010 09:09
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.


From: Lew on 22 Jan 2010 09:21
Robin Holmes wrote:
> 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?

--
Lew
From: Joshua Cranmer on 22 Jan 2010 09:43
On 01/22/2010 09:09 AM, Robin Holmes wrote:
> 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.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
First  |  Prev  | 
Pages: 1 2
Prev: Inconsistent whether new browser window opens from signed applet
Next: http bug