On Thu, May 26, 2011 at 1:58 AM, Tom Rodriguez wrote:
> but test is some ugly goo because of boxing. It's relatively easy to get the
> optimizer to fold away the boxing for boolean but sadly it doesn't help the
> performance at all. Additionally that ends up touching a fair amount of
> common
Changeset: fc655b960f84
Author:jrose
Date: 2011-05-26 00:30 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/fc655b960f84
netbeans/meth project
! netbeans/meth/nbproject/project.properties
___
mlvm-dev mailing list
mlvm-dev@openjdk.ja
Changeset: fe290680d179
Author:jrose
Date: 2011-05-26 00:45 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/fe290680d179
meth: roll up separate patch sets into 7032323
- meth-doc-7014005.2.patch
- meth-doc-7014005.patch
! meth-review-7032323.patch
! series
On May 25, 2011, at 11:04 PM, Charles Oliver Nutter wrote:
> I don't say it's not clever. It's just not something anyone is
> typically going to figure out on their own. There will be constant
> questions "if I can invalidate a SwitchPoint, why can't I ask if it
> has been invalidated?"
You are r
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
! m
Changeset: 48d38f4983fd
Author:jrose
Date: 2011-05-26 01:20 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/48d38f4983fd
meth: respond to review comments; add experimental SwitchPoint.isValid
! meth-review-7032323.patch
___
mlvm-
On May 25, 2011, at 11:58 PM, Tom Rodriguez wrote:
> Overall it seems ok. A few minor oddities:
>
> MethodHandle.java
>
> variable arity is sometimes hyphenated. It seems more correct without but be
> consistent.
Replaced hyphen by space.
> AdapterMethodHandle.java:
>
> The new value srcSl
On May 26, 2011, at 12:15 AM, Charles Oliver Nutter wrote:
> It is definitely frustrating to see that perf has degraded so much the
> past couple weeks and still not be there with the reverted code.
I second that.
I did some more cherry-picking this evening and the mlvm patch queue is now
close
On May 26, 2011, at 9:15 AM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 1:58 AM, Tom Rodriguez
> wrote:
>> but test is some ugly goo because of boxing. It's relatively easy to get
>> the optimizer to fold away the boxing for boolean but sadly it doesn't help
>> the performance at a
Changeset: a2a393ea78d5
Author:jrose
Date: 2011-05-26 01:54 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a2a393ea78d5
meth: clarify security manager check #3
! meth-review-7032323.patch
___
mlvm-dev mailing list
mlvm-dev@openj
On May 26, 2011, at 10:42 AM, Christian Thalinger wrote:
> On May 26, 2011, at 9:15 AM, Charles Oliver Nutter wrote:
>> On Thu, May 26, 2011 at 1:58 AM, Tom Rodriguez
>> wrote:
>>> but test is some ugly goo because of boxing. It's relatively easy to get
>>> the optimizer to fold away the boxing
On 2011-05-26 14.04, John Rose wrote:
> On May 26, 2011, at 12:15 AM, Charles Oliver Nutter wrote:
>
>> It is definitely frustrating to see that perf has degraded so much the
>> past couple weeks and still not be there with the reverted code.
>
> I second that.
>
> I did some more cherry-picking
On May 26, 2011, at 1:42 AM, Christian Thalinger wrote:
> Using Tom's new code doesn't make a difference since I think the meth.jar
> from John includes the reverted GWT code.
I just added a hook to test whether the GWT change matters or not. Choose
either flag setting:
java -Djava.lang.invo
Changeset: 7ec927cb3df3
Author:jrose
Date: 2011-05-26 02:16 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/7ec927cb3df3
meth: fix patch skew
! meth-deprecate.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.
On May 26, 2011, at 2:12 AM, Ola Bini wrote:
> Hey John,
>
> Something in the patch queue fails to apply cleanly:
That was quick! I noticed that when I spun the meth.jar. Fixed! -- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.
Am 26.05.2011 11:03, schrieb Christian Thalinger:
[...]
> I looked at the inlining tree of fib and everything looks good and is
> inlined. There is one invokeExact which is:
>
> @ 43 java.lang.invoke.MethodHandle::invokeExact (42 bytes) too
> big
>
> but bumping the MaxInlineSize just shows th
On May 26, 2011, at 11:24 AM, Jochen Theodorou wrote:
> Am 26.05.2011 11:03, schrieb Christian Thalinger:
> [...]
>> I looked at the inlining tree of fib and everything looks good and is
>> inlined. There is one invokeExact which is:
>>
>> @ 43 java.lang.invoke.MethodHandle::invokeExact (42 byt
On Thu, May 26, 2011 at 3:34 AM, John Rose wrote:
> I did some more cherry-picking this evening and the mlvm patch queue is now
> closer to the reality of what's in jdk7 b144.
>
> I also pushed Tom's bimorphic MH inlining code, on an experimental basis.
Ok, I'll rebuild and use current stuff for
On Thu, May 26, 2011 at 4:03 AM, Christian Thalinger
wrote:
> Is there some additional code that got added to the GWT logic or maybe some
> additional code on the JRuby side that would explain the slowdown?
The current logic is 2x faster on the 5/13 build (b141ish maybe?) of
macosx port than on
On Thu, May 26, 2011 at 4:47 AM, Charles Oliver Nutter
wrote:
> The current logic is 2x faster on the 5/13 build (b141ish maybe?) of
By "current logic" I mean "the logic in JRuby master right now". Same
JRuby logic, compared between an earlier macosx build and current mlvm
build, and the macosx b
On 05/26/2011 10:16 AM, John Rose wrote:
> On May 25, 2011, at 11:04 PM, Charles Oliver Nutter wrote:
>
>> I don't say it's not clever. It's just not something anyone is
>> typically going to figure out on their own. There will be constant
>> questions "if I can invalidate a SwitchPoint, why can't
On Thu, May 26, 2011 at 3:16 AM, John Rose wrote:
> You are right about the questions. That's one of the first things to annoy
> me about an API: mutators w/o queries.
>
> We omitted it because it's not a very trustworthy query. But it's easy to
> add.
>
> Here's possible javadoc:
>
> /**
On Thu, May 26, 2011 at 4:52 AM, Rémi Forax wrote:
> As John says, if isValid return true,
> you know nothing because it's perhaps not true anymore.
Not true. You know if it was valid when you queried it. That will be
enough for many use cases (including mine).
Your assertion could also be made
Changeset: 4e1bd8a521ea
Author:jrose
Date: 2011-05-26 02:03 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/4e1bd8a521ea
meth: add experimental GWT knob
! meth-review-7032323.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.
On 05/26/2011 11:56 AM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 4:52 AM, Rémi Forax wrote:
>> As John says, if isValid return true,
>> you know nothing because it's perhaps not true anymore.
> Not true. You know if it was valid when you queried it. That will be
> enough for many us
As far as I know there is no specific optimization of SwitchPoint
i.e there is still a volatile read in the middle of the pattern.
Rémi
On 05/26/2011 08:40 AM, Charles Oliver Nutter wrote:
> Now for something completely different: SwitchPoint-based "constant"
> lookup in JRuby.
>
> It's certainly
On Thu, May 26, 2011 at 3:42 AM, Christian Thalinger
wrote:
> I also did some performance testing. I used a recent HS repository, applied
> Tom's patch, used a recent meth.jar provided by John and this is what I got:
Somehow I stumbled past this reply...comments inline below.
> intelsdv07:~/ml
Charles,
why do you use IRubyObject exactly ?
why not using Object instead ?
I use Object in PHP.reboot and see no problem.
Rémi
On 05/26/2011 09:15 AM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 1:58 AM, Tom Rodriguez
> wrote:
>> but test is some ugly goo because of boxing. It's
Changeset: d3c86218c3f5
Author:jrose
Date: 2011-05-26 03:29 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/d3c86218c3f5
meth: respond to review comments
! meth-review-7032323.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java
On May 26, 2011, at 3:02 AM, Rémi Forax wrote:
>> ...which pretty much
>> describes all concurrently mutable state, doesn't it? ;)
>
> You're right :)
>
>> - Charlie
>
> Rémi
Caught me. :-) That didn't take long. -- John
___
mlvm-dev mailing list
On Thu, May 26, 2011 at 5:25 AM, Rémi Forax wrote:
> Charles,
> why do you use IRubyObject exactly ?
> why not using Object instead ?
>
> I use Object in PHP.reboot and see no problem.
Legacy, mostly... JRuby still supports Java 5 and 6, which limits how
specialized we can make call paths. Requir
Changeset: 1006116d2e9b
Author:jrose
Date: 2011-05-26 03:47 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/1006116d2e9b
meth: fix unit test, tweak doc
! meth-review-7032323.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.n
On 05/26/2011 12:33 PM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 5:25 AM, Rémi Forax wrote:
>> Charles,
>> why do you use IRubyObject exactly ?
>> why not using Object instead ?
>>
>> I use Object in PHP.reboot and see no problem.
> Legacy, mostly... JRuby still supports Java 5 and 6
On Thu, May 26, 2011 at 6:18 AM, Rémi Forax wrote:
> For the metaclass, the idea is to not retrieve the metaclass in the fast
> path,
> if you have one Java class for one ruby class and a 1 to 1 relation between
> a class and a metaclass, checking the class and the SwitchPoint of the
> metaclass
>
isValid looks fine.
tom
On May 26, 2011, at 1:31 AM, John Rose wrote:
> On May 25, 2011, at 11:58 PM, Tom Rodriguez wrote:
>
>> Overall it seems ok. A few minor oddities:
>>
>> MethodHandle.java
>>
>> variable arity is sometimes hyphenated. It seems more correct without but
>> be consisten
John, you state that validity is not a stable property.
Is invalidity a stable property, or not even that is.
-- ramki
(who doesn't yet know what a switchpoint is)
On 05/26/11 10:11, Tom Rodriguez wrote:
> isValid looks fine.
>
> tom
>
> On May 26, 2011, at 1:31 AM, John Rose wrote:
>
>> On Ma
On 05/26/2011 09:10 PM, Y. S. Ramakrishna wrote:
> John, you state that validity is not a stable property.
> Is invalidity a stable property, or not even that is.
yes, once invalidated a switch point can't be reverted to a valid state.
http://download.java.net/jdk7/docs/api/java/lang/invoke/Switch
Ah, i found the doc comment that "invalidity can't be reversed"
which i take to mean that invalidity is a stable property.
Under that understanding, it would seem that isInvalid()
is a better API than isValid() (on the other hand
i don't know how this query is used, since i haven't followed
the dis
Invalidity is stable because it is permanent.
-- John (on my iPhone)
On May 26, 2011, at 12:10 PM, "Y. S. Ramakrishna"
wrote:
> John, you state that validity is not a stable property.
> Is invalidity a stable property, or not even that is.
>
___
m
The method comes from a request by me, and isInvalid seems a bit
double-negativy to me. If it returns false, it's not invalid, which
means not not valid, which means valid. From a language perspective,
it seems clearer to ask if it's valid, and not have a false value
negate a negative (even if that
On May 26, 2011, at 1:21 PM, Charles Oliver Nutter wrote:
> isInvalid seems a bit double-negativy to me.
That's my hesitation. Consider the use case:
void maybeCleanUpMess(SwitchPoint sp) {
if (!mysp.isInvalid()) return;
... // do cleanup after invalidation
}
It reads better as:
Changeset: 5ebf0fbafd90
Author:jrose
Date: 2011-05-26 13:40 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/5ebf0fbafd90
meth-deprecate: adjust doc, remove strawmen
! meth-deprecate.patch
___
mlvm-dev mailing list
mlvm-dev@openjd
Changeset: a58ad137e1de
Author:jrose
Date: 2011-05-26 13:49 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a58ad137e1de
meth-deprecate: move experimenta GWT hook into its own patch; tweak doc
+ meth-experiment.patch
! meth-review-7032323.patch
! series
___
Yes, agreed. But one could also write:
> void maybeCleanUpMess(SwitchPoint sp) {
> if (mysp.isInvalid()) {
> ... // do cleanup after invalidation
} // else nothing to do
> }
I don't know if one style is better than the other
generally.
It's just that doing something bas
There's something deeply bizarro about that assembly. It looks like x64
assembly decoded by the 32 assembler. I think your hsdis wasn't built right.
tom
On May 26, 2011, at 2:13 PM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 1:58 AM, Tom Rodriguez
> wrote:
>>> Great to hear this
Hmm, I'll look into it. I used the amd64 build from the hsdis project
on kenai...
On Thu, May 26, 2011 at 4:27 PM, Tom Rodriguez wrote:
> There's something deeply bizarro about that assembly. It looks like x64
> assembly decoded by the 32 assembler. I think your hsdis wasn't built right.
>
> t
On May 26, 2011, at 2:43 PM, Charles Oliver Nutter wrote:
> Hmm, I'll look into it. I used the amd64 build from the hsdis project
I posted the bsd/amd64 libdis when I was desperate for something that would at
least link and partially decode instructions. But that hsdis binary doesn't
really kn
I see someone tagged that build as "broken" now on Kenai. Can someone
with the appropriate skills do a non-broken build? I've never build
the hsdis plugin (but I'm attempting to now.
- Charlie
On Thu, May 26, 2011 at 4:43 PM, Charles Oliver Nutter
wrote:
> Hmm, I'll look into it. I used the amd6
On Thu, May 26, 2011 at 5:16 PM, John Rose wrote:
> I posted the bsd/amd64 libdis when I was desperate for something that would
> at least link and partially decode instructions. But that hsdis binary
> doesn't really know about x64 disassembly. (The base project doesn't support
> x64. The g
On May 26, 2011, at 3:45 PM, Charles Oliver Nutter wrote:
> Ahh...well is there another binary you can point me at? Otherwise,
> I'll just do i386 asm for now.
I tagged it. It's broken in the sense that it's a brutal 64-bit build of code
designed only for 32-bit disassembly.
I suggest doing at
On Thu, May 26, 2011 at 6:00 PM, John Rose wrote:
> I tagged it. It's broken in the sense that it's a brutal 64-bit build of
> code designed only for 32-bit disassembly.
>
> I suggest doing at least some of these investigations with 32-bit builds.
> (But, we do need a binutils-based hsdis!)
N
I'll see what I can do on my mac.
tom
On May 26, 2011, at 3:45 PM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 5:16 PM, John Rose wrote:
>> I posted the bsd/amd64 libdis when I was desperate for something that would
>> at least link and partially decode instructions. But that hsdis
On May 26, 2011, at 10:11 AM, Tom Rodriguez wrote:
> isValid looks fine.
Thanks Tom. I also corrected the javadoc, added a demo of isValid and copied
the javadoc example into the unit tests.
-- John
diff --git a/src/share/classes/java/lang/invoke/SwitchPoint.java
b/src/share/classes/java/lan
Changeset: d00ba9ebe2c7
Author:jrose
Date: 2011-05-26 16:43 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/d00ba9ebe2c7
meth: fix javadoc example for SwitchPoint; make jcheck happy
! meth-review-7032323.patch
___
mlvm-dev mailin
On Thu, May 26, 2011 at 5:20 AM, Rémi Forax wrote:
> As far as I know there is no specific optimization of SwitchPoint
> i.e there is still a volatile read in the middle of the pattern.
If that's true I'm not sure how this is better than a regular GWT with
a volatile read in the test.
- Charlie
On 05/27/2011 01:53 AM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 5:20 AM, Rémi Forax wrote:
>> As far as I know there is no specific optimization of SwitchPoint
>> i.e there is still a volatile read in the middle of the pattern.
> If that's true I'm not sure how this is better than a
On May 26, 2011, at 4:53 PM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 5:20 AM, Rémi Forax wrote:
>> As far as I know there is no specific optimization of SwitchPoint
>> i.e there is still a volatile read in the middle of the pattern.
>
> If that's true I'm not sure how this is bett
On Thu, May 26, 2011 at 7:09 PM, Rémi Forax wrote:
> It will be better when SwitchPoint will be optimized,
> the major point of having the SwitchPoint API is,
> like most of the API of java.lang.invoke,
> that these API are/will be recognized and optimized by the VM.
Ok, whew...I thought I misund
What Remi said. -- John
On May 26, 2011, at 5:09 PM, Rémi Forax wrote:
> the major point of having the SwitchPoint API is,
> like most of the API of java.lang.invoke,
> that these API are/will be recognized and optimized by the VM.
___
mlvm-dev mailin
On Thu, May 26, 2011 at 7:13 PM, John Rose wrote:
> It's probably about the same as GWT+volatile right now; actually there's a
> MCS with a memory barrier in the present code.
> But since SwitchPoint is a clear pattern it can be optimized in the future.
> It's clear the user of a SwitchPoint want
On May 26, 2011, at 5:18 PM, Charles Oliver Nutter wrote:
> Some combination of
> these flags will be enabled by default as they get optimized in
> Hotspot. That should allow having things "on" as they're ready to be
> on by default.
That's the way we do it in the JVM also, on works-in-progress w
Oh, forgot to include dynopt numbers under that older macosx build:
~/projects/jruby ➔ jruby -Xcompile.dynopt=true
-Xinvokedynamic.invocation=false --server -J-d32
bench/bench_fib_recursive.rb 5 35
9227465
1.366000 0.00 1.366000 ( 1.293000)
9227465
0.949000 0.00 0.949000 ( 0.
I wanted to outline how I plan to make JRuby's current class
modification check eventually be all SwitchPoint driven.
JRuby, like some other dynamic languages, allows runtime modification
of pretty much every class in the system. Usually this only happens at
boot time, but since it can potentially
Another data point...bench_method_dispatch_only. Review: this bench
benchmarks the overhead of a while loop and dynamic invocations of a
trivial Ruby method. It is intended to benchmark (mostly) the overhead
of making a dyncall, and the ability of the VM to optimize away
mostly-dead logic.
The ben
On Thu, May 26, 2011 at 8:40 PM, Charles Oliver Nutter
wrote:
> dynopt is interesting for comparison:
>
> ~/projects/jruby ➔ jruby --server -J-d32 -Xjit.threshold=2
> -Xcompile.invokedynamic=false -Xcompile.dynopt=true
> -Xinvokedynamic.constants=false
> bench/language/bench_method_dispatch_only.r
That sounds right.
On May 26, 2011, at 6:31 PM, Charles Oliver Nutter wrote:
> * For a descendant hierarchy of N classes, I'll need to do N
> invalidateAll calls. This is not ideal, since those calls are very
> heavy.
Fully optimized invalidations will use safepoints. The point of using an arra
On Thu, May 26, 2011 at 9:02 PM, John Rose wrote:
> Fully optimized invalidations will use safepoints. The point of using an
> array is to allow any number of switchpoints to ride on one safepoint. Can
> you batch all the invalidations in a given hierarchy of N classes? Or is
> there an orde
Hi,
I just built a new JDK and ran everything with it. The good news is that
the problem with the missing class doesn't show up anymore.
However, I still see the ShouldNotReachHere problem:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (frame.cpp:1158),
Hi,
It seems there is still a difference in how asType MHs work between what
is in current JDK7 repo, and what you get from building bsdport with
mlvm patches. Specifically, when running things with bsdport/mlvm they
work. When running on JDK7 (built about 30 minutes ago) I get this:
Caused by: j
On May 26, 2011, at 11:38 PM, Ola Bini wrote:
> It seems there is still a difference in how asType MHs work between what
> is in current JDK7 repo, and what you get from building bsdport with
> mlvm patches. Specifically, when running things with bsdport/mlvm they
> work. When running on JDK7 (bui
70 matches
Mail list logo
