slow performance of loom continuations

[seth lytle]

thanks for taking a look Alan (and for the work on loom). yeah, there are a
lot of considerations to balance in all of this and to some degree even i
am sympathetic to the desire to cover more code at the expense of tight
loops since we already have workable solutions for the state machine type
stuff. for now i'll plan on a hybrid approach, keeping kilim for the state
machines but allowing higher level interaction with arbitrary code using a
bridge to project loom (i'm trying to get a narrative together for how
project loom will impact my project and decide what to work on next)

if the team is interested in a JMH version of this Xorshift example, i'd be
willing to work on that. but my gut is that it's much too early for that to
be useful (premature optimization ... etc), especially since it may end up
being a use-case you're not prioritizing for anyway

and finally i wanted to say, it's really exciting to be calling
continuation-based code from the command line without a classpath, pom or
compilation !




On Mon, Sep 10, 2018 at 12:18 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 07/09/2018 05:47, seth lytle wrote:
>
>> :
>>
>> am i using the api correctly ? i do use exceptions in other continuations,
>> so UseNewCode isn't really an option for me
>>
>> i realize that this is an early prototype. do you have any idea what
>> performance you're ultimately shooting for for this sort of loop ?
>>
>> is there a tradeoff between performance in these simple cases and being
>> able to weave "most" production code ?
>>
>> I skimmed through the code in your mail and you appear to be using
> continuation API correctly. It's early days in this project and too early
> to draw any conclusions on whether the approach to freezing and thawing the
> stack is the best approach or not. One performance issue is the current
> prototype is the detection of monitors in compiled frames - you can use
> -XX:-DetectLocksInCompiledFrames to workaround that issue temporarily
> which should help your test a bit (but not significantly).  Yes, there are
> trade-offs when comparing it to approaches that employ state machines and
> bytecode re-writing.
>
> -Alan
>