On 07/07/2012 04:54 AM, Mark Roos wrote:
Hi Rémi, you mention
And now the trick, there is a nice way (several in fact) to explain to
the JIT
that even if the bytecode contains tests, if the variable contains
effectively an int,
it's a good idea to remove them.
Ok, in Smalltalk there are
Changeset: 05e2216c0b10
Author:jrose
Date: 2012-07-07 05:51 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/05e2216c0b10
meth: work through cleanups; fix bugs
! meth-lazy-7023639.patch
! meth-lazy-7023639.xbmh.patch
___
mlvm-dev
Changeset: 4799b4508e19
Author:jrose
Date: 2012-07-07 05:52 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/4799b4508e19
meth: coordinate ports (x86_{32,64}, sparc); work through cleanups; fix bugs
! meth-lazy-7023639.jit.patch
! meth-lazy-7023639.patch
On Jul 7, 2012, at 1:56 AM, Rémi Forax wrote:
You have also to figure out how to get two return values from a method call,
but exceptions are your best friend here.
Can you give an example of what you mean here? Also, from all the
presentations I've seen on the JVM, exceptions are very
On 07/07/2012 07:02 PM, Dain Sundstrom wrote:
On Jul 7, 2012, at 1:56 AM, Rémi Forax wrote:
You have also to figure out how to get two return values from a method call,
but exceptions are your best friend here.
Can you give an example of what you mean here? Also, from all the
presentations
Here's a blog post from John Rose explaining that exception throwing
compiles to a goto in cases like this:
https://blogs.oracle.com/jrose/entry/longjumps_considered_inexpensive
Sent from my phone
On Jul 7, 2012 2:43 PM, Rémi Forax fo...@univ-mlv.fr wrote:
On 07/07/2012 07:02 PM, Dain Sundstrom
Wow. That dramatically changes my mental model of exceptions in the JVM. This
is going to dramatically simplify some of my code.
thanks
-dain
On Jul 7, 2012, at 11:48 AM, Vitaly Davidovich wrote:
Here's a blog post from John Rose explaining that exception throwing compiles
to a goto in
Thanks Rémi, good example
is big compared to the code of the generated assembler so the JIT may
decide to not inline something
I assume that changing the maxInline will fix this if its an issue
You have also to figure out how to get two return values from a method
call,
but exceptions are
On 07/08/2012 12:03 AM, Charles Oliver Nutter wrote:
Today I have a new conundrum for you all: I need stack trace
generation on Hotspot to be considerably faster than it is now.
In order to simulate many Ruby features, JRuby (over)uses Java stack
traces. We recently (JRuby 1.6, about a year
On Saturday, July 7, 2012, Rémi Forax wrote:
You can use Throwable.**getStackTraceElement()
which is package visible and OpenJDK specific but at least
it will be faster for all VMs that uses OpenJDK.
I'll certainly explore that to see if it improves the situation. If it's
faster, it might be
On 07/08/2012 12:50 AM, Charles Oliver Nutter wrote:
On Saturday, July 7, 2012, Rémi Forax wrote:
You can use Throwable.getStackTraceElement()
which is package visible and OpenJDK specific but at least
it will be faster for all VMs that uses OpenJDK.
I'll certainly explore that
Changeset: f3998b83fe97
Author:jrose
Date: 2012-07-07 18:00 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f3998b83fe97
meth: cleanups
! meth-lazy-7023639.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
Changeset: b06d7d2b0f2f
Author:jrose
Date: 2012-07-07 22:03 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b06d7d2b0f2f
rebase to current hsx/hotspot-comp
! series
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
Changeset: 9b610da8ef26
Author:jrose
Date: 2012-07-07 22:06 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9b610da8ef26
rebase to current hsx/hotspot-comp; add contributed draft for 7177472
+ meth-7177472.patch
- meth-experiment.patch
! meth-lazy-7023639.patch
! series
14 matches
Mail list logo
