Looks fine to me.
Vladimir K
On 3/23/15 5:27 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8062280/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8062280
C2 inlining policy is too strict when it comes to inlining DMH linkers.
The compiler performs access checks on
http://cr.openjdk.java.net/~vlivanov/8062280/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8062280
C2 inlining policy is too strict when it comes to inlining DMH linkers.
The compiler performs access checks on target method and sometimes it
breaks inlining. Such checks can be skipped
k.java.net/browse/JDK-8071787
For testing & performance measurements, sometimes it's useful to replace block
inlining wrappers with trivial reinvokers.
This change extends DONT_INLINE_THRESHOLD in the following manner:
DONT_INLINE_THRESHOLD = -1: no wrapper
DONT_INLINE_THRESH
measurements, sometimes it's useful to replace
> block inlining wrappers with trivial reinvokers.
>
> This change extends DONT_INLINE_THRESHOLD in the following manner:
> DONT_INLINE_THRESHOLD = -1: no wrapper
> DONT_INLINE_THRESHOLD = 0: reinvoker
> DONT_INLI
http://cr.openjdk.java.net/~vlivanov/8071787/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8071787
For testing & performance measurements, sometimes it's useful to replace
block inlining wrappers with trivial reinvokers.
This change extends DONT_INLINE_THRESHOLD in the followi
.invokeExact() ?
>> We introduced that annotation as an experiment for inlining exact invokers
>> for LambdaForms (note: LambdaForm is not directly related to Project
>> Lambda). The generated bytecode versions of these LFs are usually just
>> argument shuffling or bindin
On 05/09/2012 08:02 PM, Christian Thalinger wrote:
> On May 8, 2012, at 2:11 AM, Garcia Gutierrez Miguel Alfredo wrote:
>
>> What's the behavior of @ForceInlining , in particular for
>> MethodHandle.invokeExact() ?
> We introduced that annotation as an experiment f
On May 8, 2012, at 2:11 AM, Garcia Gutierrez Miguel Alfredo wrote:
>
> What's the behavior of @ForceInlining , in particular for
> MethodHandle.invokeExact() ?
We introduced that annotation as an experiment for inlining exact invokers for
LambdaForms (note: LambdaForm i
f.foo() is a megamorphic call so the inlining cache does not work,
too many possible receiver types, so the inlining cache tree
is like a linked list, painfully.
With a language like Java, the VM will fallback to use
a vtable dispatch, you have no inlining but it's faster than
either updat
What's the behavior of @ForceInlining , in particular for
MethodHandle.invokeExact() ?
The context for this question is ongoing brainstorming on a new compilation
scheme for the Scala compiler:
http://mail.openjdk.java.net/pipermail/graal-dev/2012-May/38.html
http://mail.openjdk.java.n
Hi all,
I have the feeling we have talked about this already, but I couldn't
really find it and back then it was independend of invokedynamic...
Anyway...
Assuming I have an interface Foo with a void method foo(). And assuming
I have the class Bar0, Bar1 to BarN implementing that interface. L
ected (for fast/slow splits), selectAlternative will have a fast/slow
>>>>> profile, just like the original GWT invokers.
>>>>>
>>>>> The PROB_FAIR in CallGenerator::for_method_handle_inline could be made
>>>>> "smarter",
On 06/21/2011 09:36 AM, John Rose wrote:
On Jun 21, 2011, at 12:31 AM, Rémi Forax wrote:
Sorry Mark and Tom, I should have been more clear.
The idea is to artificially put a "never seen" flag in front of the
*last* fallback
in the GWT chain.
Yes. One way to do this is with a VM-internal co
On 06/21/2011 09:50 AM, Mark Roos wrote:
Thanks for the example Rémi
Out of curiosity why is the fallback method synchronized? Something
to do with SwitchPoints?
No, SwitchPoint primary use case is metaclass modification/alteration.
The problem is that several threads may want to update the
On 06/21/2011 05:43 AM, Mark Roos wrote:
John Rose stated
See section 5, "Case Study: Inline Caches and invokedynamic".
Thanks John, I have read that several times and it is very helpful
A small (non-megamorphic) polymorphic cache can be represented
as a cascade or decision tr
Thanks for the example Rémi
Out of curiosity why is the fallback method synchronized? Something to do
with SwitchPoints?
thanks
mark
From:
Rémi Forax
To:
mlvm-dev@openjdk.java.net
Date:
06/21/2011 12:28 AM
Subject:
Re: Inlining heuristic trouble
Sent by:
mlvm-dev-boun...@openjdk.java.net
On Jun 21, 2011, at 12:31 AM, Rémi Forax wrote:
> Sorry Mark and Tom, I should have been more clear.
> The idea is to artificially put a "never seen" flag in front of the *last*
> fallback
> in the GWT chain.
Yes. One way to do this is with a VM-internal combinator that simply notes
execution
On 06/20/2011 10:11 PM, Mark Roos wrote:
Not that I am the expert here but...
In the Smalltalk we are porting the typical call site supports only a
few actual classes. So the method look up ( which is based on the
object class )
only chooses from a small set ( mostly a single choice). This s
e argument list, and then you jump to an
> invoker.) This can support vtable or metaclass dispatches, or more subtle
> ones like the CLOS dispatch via a hash of relevant argument attributes.
>
> (I'm getting hungry for Remi's cookbook, because it will have this sort of
> example
John Rose stated
See section 5, "Case Study: Inline Caches and invokedynamic".
Thanks John, I have read that several times and it is very helpful
A small (non-megamorphic) polymorphic cache can be represented as
a cascade or decision tree of GWT combinators, probab
gt;>>>
>>>> The PROB_FAIR in CallGenerator::for_method_handle_inline could be made
>>>> "smarter", by feeding from the control inputs of the Phi; that would be a
>>>> good start.
>>> Well duh on me. When I wrote that my brain was
On Jun 20, 2011, at 3:06 PM, Charles Oliver Nutter wrote:
> ...and as a result the inlining heuristics would behave the same as if we'd
> written the above in Java by hand. Interesting to note: currently, the first
> cached result ends up further down the list. In other words, i
On Jun 20, 2011, at 1:11 PM, Mark Roos wrote:
> So we do not have a path that can be assumed to be not taken (except the last
> in the chain).
>
> Perhaps in the JVM this is a poor choice for implementation of a small
> polymorphic inline cache. Here I defer to the real experts
Both monomor
).
>
This is the same for JRuby. My assumption has been that the inlined version
of that chain of GWT would look like this to the JVM:
if (test1()) { target1(); }
else if (test2()) { target2(); }
else if (test3()) { target3(); }
else { fallback(); }
...and as a result the inlining heuristics
inline cache. Here I defer to the real experts
regards
mark
From:
Tom Rodriguez
To:
Da Vinci Machine Project
Date:
06/20/2011 12:18 PM
Subject:
Re: Inlining heuristic trouble
Sent by:
mlvm-dev-boun...@openjdk.java.net
On Jun 18, 2011, at 5:15 AM, Rémi Forax wrote:
> On 06/18/2011
ing from the control inputs of the Phi; that would be a
>>> good start.
>> Well duh on me. When I wrote that my brain was thinking cmove instruction,
>> not a real If diamond with probability. I don't think fixing this will
>> improve the inlining in the fast
just like the original GWT invokers.
>>
>> The PROB_FAIR in CallGenerator::for_method_handle_inline could be made
>> "smarter", by feeding from the control inputs of the Phi; that would be a
>> good start.
> Well duh on me. When I wrote that my brain was thinking c
_handle_inline could be made
> "smarter", by feeding from the control inputs of the Phi; that would be a
> good start.
Well duh on me. When I wrote that my brain was thinking cmove instruction, not
a real If diamond with probability. I don't think fixing this will improv
On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
>>
>> Sorry, I was thinking recording which branch of the GWT is taken and
>> storing them in the GWT.
>> Two GWTs should not share the same metadata.
>
> This is the major problem with GWT/selectAlternative. Previously when GWT
> was bytecod
On Jun 17, 2011, at 3:06 AM, Rémi Forax wrote:
> On 06/17/2011 11:50 AM, Christian Thalinger wrote:
>
> [...]
>
>>> I wonder if I haven't introduce a bug in my logic,
>>> there is a the boxing/unboxing of the return value of the test that
>>> should not occur.
>>> Question, does EA is also disa
On 06/17/2011 11:50 AM, Christian Thalinger wrote:
[...]
>> I wonder if I haven't introduce a bug in my logic,
>> there is a the boxing/unboxing of the return value of the test that
>> should not occur.
>> Question, does EA is also disable when MH.invokeExact is called ?
> Yes, as MH.invokeExact
he VM logs, the method containing (j != MAXINT) is not inlined
>>> because it hits the maximum depth (as far as I remember this problem
>>> is new, the older algorithm, the one that didn't propagate MDO, didn't
>>> exhibit this problem).
>> I fixed a small
logs, the method containing (j != MAXINT) is not inlined
>>> because it hits the maximum depth (as far as I remember this problem
>>> is new, the older algorithm, the one that didn't propagate MDO, didn't
>>> exhibit this problem).
>> I fixed a small bug i
is problem
>> is new, the older algorithm, the one that didn't propagate MDO, didn't
>> exhibit this problem).
> I fixed a small bug in printing the inlining tree with nested MHs (we're
> getting flat trees in this case). Anyway, the inlining for PerfOpt looks
>
lem in my code so ... :)
> Playing with the VM logs, the method containing (j != MAXINT) is not inlined
> because it hits the maximum depth (as far as I remember this problem
> is new, the older algorithm, the one that didn't propagate MDO, didn't
> exhibit this problem).
I f
On Jun 15, 2011, at 5:48 PM, Christian Thalinger wrote:
> On Jun 15, 2011, at 5:26 PM, Rémi Forax wrote:
>> I've just finished to code a sample for the cookbook that does
>> integer operation (+ and -) with overflow (to BigInteger).
>>
>> https://code.google.com/p/jsr292-cookbook/source/browse/#sv
On Jun 15, 2011, at 5:26 PM, Rémi Forax wrote:
> I've just finished to code a sample for the cookbook that does
> integer operation (+ and -) with overflow (to BigInteger).
>
> https://code.google.com/p/jsr292-cookbook/source/browse/#svn%2Ftrunk%2Fbinary-operation%2Fsrc%2Fjsr292%2Fcookbook%2Fbinop
I've just finished to code a sample for the cookbook that does
integer operation (+ and -) with overflow (to BigInteger).
https://code.google.com/p/jsr292-cookbook/source/browse/#svn%2Ftrunk%2Fbinary-operation%2Fsrc%2Fjsr292%2Fcookbook%2Fbinop
For a code like this one:
max = ...
for(i=0; ihttp://
dHandle::invokeExact (9 bytes) inline (hot)
> @ 2
> sun.invoke.util.ValueConversions::identity (2 bytes) inline (hot)
> \-> discounting inline depth
I need to do an updated run. It's certainly possible i
On Jun 7, 2011, at 10:44 PM, Charles Oliver Nutter wrote:
> That's pretty much it. The test I ran looks like this:
>
> def foo
> 1
> end
>
> 100_000.times {
> foo
> }
>
>
> The body of the block passed to "times" jits (in Hotspot) and appears
> to inline the "foo" method just fine, but the bod
An update:
Almost all literals and several non-literal-but-constructed-once
syntax niblets from Ruby are now constructed through invokedynamic.
Most of these use the "one time only" model, patching the call site
with a MethodHandles.constant from then on. The runtime constructs are
always on; the
On Wed, Jun 8, 2011 at 12:22 AM, John Rose wrote:
> What is the type you pass to MHs.constant? If it's not Object, call it T.
The more direct answer: it's T...in my case, the actual type of the
object given. I expected that to be better than making it Object and
wrapping it in an explicitCast or
On Wed, Jun 8, 2011 at 12:44 AM, Charles Oliver Nutter
wrote:
> Looking at the PrintAssemblyOutput at the point of that suspicious callq:
Bleh. PrintAssembly output formats horribly when wrapped to 80 columns :)
Here it is in a gist, for the longer-form test I ran:
https://gist.github.com/101385
Simplest way to show it is to show it.
For a simple Fixnum literal, lazily initialized when first encountered:
jruby -e "puts 1"
Bytecode emitted:
ALOAD 1 (this is ThreadContext)
INVOKEDYNAMIC getFixnum
(Lorg/jruby/runtime/ThreadContext;)Lorg/jruby/RubyFixnum;
[org/jruby/runtime/invoked
On Jun 7, 2011, at 3:38 PM, Charles Oliver Nutter wrote:
> So I figured I'd check assembly output, and I was surprised to see a
> callq right where I expect to see the literal. Are
> MethodHandle.constant handles not inlined right now?
Here is what constant(Object.class, foo) reduces to:
#wellK
first call, there's no overhead other than
> traversing the MutableCallSite and a dropArguments handle. Quite
> slick, and especially interesting since it improves inlining budgeting
> and bytecode size substantially (since it cuts out the extra
> args/calls and the test + load from th
ck, and especially interesting since it improves inlining budgeting
and bytecode size substantially (since it cuts out the extra
args/calls and the test + load from that per-script array).
So I figured I'd check assembly output, and I was surprised to see a
callq right whe
Changeset: 2e2b46407389
Author:jrose
Date: 2011-05-26 00:48 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2e2b46407389
meth: add upcoming fixes; add experimental bimorphic MH inlining; cherry pick
more hotspot-comp changes
+ meth-bim.patch
+ meth-gc-7018355.patch
On 05/18/2011 09:03 PM, John Rose wrote:
> On May 18, 2011, at 11:59 AM, Rémi Forax wrote:
>
>> All others are hard because the value of the method handle is not
>> statically known
>> i.e the method handle cannot be considered as constant.
> It can be optimistically inlined, which is what we do fo
On May 18, 2011, at 11:59 AM, Rémi Forax wrote:
> All others are hard because the value of the method handle is not
> statically known
> i.e the method handle cannot be considered as constant.
It can be optimistically inlined, which is what we do for invokedynamic
instructions.
-- John
___
On 05/18/2011 06:44 PM, Charles Oliver Nutter wrote:
> On Wed, May 18, 2011 at 5:34 AM, Szymon Jachim wrote:
>> I have to questions to you guys about possible (and planned) JIT
>> optimizations for MethodHandles.
>> 1. Assuming that there will be a chain of MH's:
>>mh1(invoker) -> mh2 ->
On Wed, May 18, 2011 at 5:34 AM, Szymon Jachim wrote:
> I have to questions to you guys about possible (and planned) JIT
> optimizations for MethodHandles.
> 1. Assuming that there will be a chain of MH's:
> mh1(invoker) -> mh2 -> aMethod()
> and there will be no other references to mh2.
I have to questions to you guys about possible (and planned) JIT
optimizations for MethodHandles.
1. Assuming that there will be a chain of MH's:
mh1(invoker) -> mh2 -> aMethod()
and there will be no other references to mh2. Will JIT/GC be able to
optimize unneeded mh2 and put into callsi
On Feb 3, 2011, at 1:17 PM, Charles Oliver Nutter wrote:
> I'm ready to update it once MLVM changes have settled down.
Huff, puff... Soon! -- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-d
On Thu, Feb 3, 2011 at 3:56 PM, Rémi Forax wrote:
> Charles, do you use ASM 4 or ASM 3.3 ?
I am still using ASM 3.3 and Linkage to bind indy call sites.
- Charlie
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/
some time this weekend updating JRuby's indy support. But this
>>> email is to ask about the inlining flag tweaks that still seem to be
>>> required.
>> Does this mean I can update my JRuby repository, recompile and use it with a
>> recent JDK7 build?
> It w
On Thu, Feb 3, 2011 at 6:33 AM, Christian Thalinger
wrote:
> On Jan 31, 2011, at 8:39 PM, Charles Oliver Nutter wrote:
>> Hello friends! After months on "vacation" from indy, I managed to
>> spend some time this weekend updating JRuby's indy support. But this
>>
On Jan 31, 2011, at 8:39 PM, Charles Oliver Nutter wrote:
> Hello friends! After months on "vacation" from indy, I managed to
> spend some time this weekend updating JRuby's indy support. But this
> email is to ask about the inlining flag tweaks that still seem to be
>
On Jan 31, 2011, at 8:39 PM, Charles Oliver Nutter wrote:
> Hello friends! After months on "vacation" from indy, I managed to
> spend some time this weekend updating JRuby's indy support. But this
> email is to ask about the inlining flag tweaks that still seem to be
>
This is an auto-replied message. I am out of office until Feb 7th with limited
access to email.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Hello friends! After months on "vacation" from indy, I managed to
spend some time this weekend updating JRuby's indy support. But this
email is to ask about the inlining flag tweaks that still seem to be
required.
First, the good news: using a fastdebug build of MLVM from Stephen
On 02/16/10 07:04 PM, Raffaello Giulietti wrote:
> I asked because this kind of inlining seems quite clever to my
> uneducated eyes. Inlining, in m() or at other call sites, only a part of
> ensureSomething() while skipping the other heavier part and morphing it
> to another cal
On 2010-02-16 17:09, Christian Thalinger wrote:
> On 02/16/10 03:07 PM, Raffaello Giulietti wrote:
>> A general question about inlining. Take the following code:
>>
>> void m() {
>> ensureSomething();
>> ...
>> }
>>
>> voi
On 02/16/10 03:07 PM, Raffaello Giulietti wrote:
> A general question about inlining. Take the following code:
>
> void m() {
> ensureSomething();
> ...
> }
>
> void ensureSomething() {
> if (someTest()) return;
> doSomething();
> }
>
> boo
A general question about inlining. Take the following code:
void m() {
ensureSomething();
...
}
void ensureSomething() {
if (someTest()) return;
doSomething();
}
boolean someTest() {
return ... // a simple boolean expression;
}
void doSomething() {
// heavy and long
Christian Thalinger wrote:
> On Mon, 2009-11-16 at 16:32 +0100, Raffaello Giulietti wrote:
>> Not directly related to the mlvm but just for my own curiosity:
>>
>> * Is HotSpot able to inline JNI calls?
>> * If so, what are the prerequisites?
>> * Or are there plans to add this optimization?
>
> C
On Mon, 2009-11-16 at 16:32 +0100, Raffaello Giulietti wrote:
> Not directly related to the mlvm but just for my own curiosity:
>
> * Is HotSpot able to inline JNI calls?
> * If so, what are the prerequisites?
> * Or are there plans to add this optimization?
C2 (not sure about C1) can inline (int
Not directly related to the mlvm but just for my own curiosity:
* Is HotSpot able to inline JNI calls?
* If so, what are the prerequisites?
* Or are there plans to add this optimization?
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.op
Raffaello Giulietti wrote:
> OK, I tried with the GWT solution. It is 4 times slower than my own
> schema. But I'm using a mlvm build from a couple of weeks ago. According
> to Christian
> (http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-August/001049.html),
> only direct mh are inlined with o
nvoke_0 above.
>>> However, every call site has its own Stub instance, so every call site
>>> caches its own information.
>>>
>>> But you state
>>>
>>>> It sounds like you're still dispatching through a generic piece of
>>>> cod
caches its own information.
>>
>> But you state
>>
>>> It sounds like you're still dispatching through a generic piece of
>>> code, yes? If you have a piece of code in the call path that all calls
>>> pass through, you essentially defeat inlining
hing through a generic piece of
>> code, yes? If you have a piece of code in the call path that all calls
>> pass through, you essentially defeat inlining entirely.
>
> Why is this so? I cannot see why invoke_0 couldn't be inlined at the
> invokedynamic call site. Is there
ut you state
> It sounds like you're still dispatching through a generic piece of
> code, yes? If you have a piece of code in the call path that all calls
> pass through, you essentially defeat inlining entirely.
Why is this so? I cannot see why invoke_0 couldn't be inlined at th
> This scheme thus implements a simple inline caching solution.
It sounds like you're still dispatching through a generic piece of
code, yes? If you have a piece of code in the call path that all calls
pass through, you essentially defeat inlining entirely. JRuby runs
like this in normal mo
>
> Ugh. I never saw that assert. Maybe John Rose knows more about that one.
>
> -- Christian
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
I extensively cleaned up and refactored m
Raffaello Giulietti wrote:
> Christian, your worries were well founded.
>
> In fact, the target handler of the invokedynamic was not a direct MH but
> a bound MH, instead. I forgot about my own implementation :-(
>
> I have know refactored the code to make use of DMHs by storing the bound
> argum
Raffaello Giulietti wrote:
> Christian Thalinger wrote:
>> Raffaello Giulietti wrote:
>>> * Is there a special -XX: flag to turn on inlining of methods invoked
>>> via method handles?
>>> * Or must something be enabled during the build of mlvm?
>> No,
Raffaello Giulietti wrote:
> Christian Thalinger wrote:
>> Raffaello Giulietti wrote:
>>> * Is there a special -XX: flag to turn on inlining of methods invoked
>>> via method handles?
>>> * Or must something be enabled during the build of mlvm?
>> No,
Christian Thalinger wrote:
> Raffaello Giulietti wrote:
>> * Is there a special -XX: flag to turn on inlining of methods invoked
>> via method handles?
>> * Or must something be enabled during the build of mlvm?
>
> No, inlining is enabled by default. Currently onl
Raffaello Giulietti wrote:
> * Is there a special -XX: flag to turn on inlining of methods invoked
> via method handles?
> * Or must something be enabled during the build of mlvm?
No, inlining is enabled by default. Currently only DMH invokes are
inlined, but I'm working on inl
* Is there a special -XX: flag to turn on inlining of methods invoked
via method handles?
* Or must something be enabled during the build of mlvm?
Thanks
Raffaello
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman
ction. That's what you
> want, right?
Ultimately, yes :-)
>> So is it possible to by-pass this call sun.dyn.FromGeneric
>> $A2::invoke_I2 ?
>> Or is it possible to have a call like
>> sun.dyn.FromGeneric$A2::invoke_I2, but with (II)I.
>
> After inlining it
Then, I tested calling InvokeDynamic."plus"(Object, Object)
> also with the above target.
> This time I used the Fibonacci program, and JVM crashed. Although it
> crashed, the inlining
> information is really interesting to me. You cal see the full log
> f
ove target
and it is running fine, although it's not inlined. C2 was trying to
inline it, but it failed.
See the log here [1].
Then, I tested calling InvokeDynamic."plus"(Object, Object)
also with the above target.
This time I used the Fibonacci program, and JVM crashed. Although it
c
84 matches
Mail list logo
