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 the
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 expe
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
> presen
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" wrote:
> On 07/07/2012 07:02 PM, Dain Sundstrom wrote:
> > On
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 you
Hi Mark, nice plan
I was intrigued by the statement:
Therefore, this work will provide a likely basis for efficient
representation of the
functional ?SAM? objects required by Project Lambda, and
perhaps other future constructs, such as tuple objects or hybrid
arrays
Hi Dain
I use exceptions to handle non local returns in ST which are not
exceptional ( happen alot).
I did a quick look at the timing and the throw/catch was not slow.
I believe John Rose has a blog entry on it
mark
From: Dain Sundstrom
To: Da Vinci Machine Project
Date: 07/07/2012
On Sat, Jul 7, 2012 at 1:45 PM, Rémi Forax wrote:
> Exception are not expensive if you throw them and just catch them (and
> don't use them) in the same inlining horizon,
> so you can use them to implement non Java control flow without thinking
> too much.
Important to note here that if they don'
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 ago) moved to using the
Java stack trace as the source of o
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 ye
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
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
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
http://mail.ope
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
http://m
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
__
>From Charile
Any thoughts on this? Does anyone else have need for lighter-weight
name/file/line inspection of the call stack?
Yeah I need it for my debugger and error displays. But I need it for
suspended threads
( my debugging steps ) as well as for exceptions. And for exceptions it
would b
19 matches
Mail list logo
