VM Tech Summit 2016 update

[Marcus Lagergren]

Hi guys!

I just wanted to inform you that Paul Sandoz sadly couldn’t make it to JFokus 
and the VM Tech Summit in February. Luckily we have found Simon Ritter to 
replace him. Simon will be wearing his Azul hat, and will talk about the Object 
Layout project (objectlayout.org).

The speaker list has been updated.

https://www.jfokus.se/jfokus/jvmtech.jsp 


Hope to see you there!
/Marcus (VM Tech summit chair and coordinator)



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: JFokus VM Tech Day 2016

[Marcus Lagergren]

Guys. Sadly Paul couldn’t make it, but we have replaced him with Simon Ritter, 
who will be wearing his new Azul hat. You are all welcome to attend!

https://www.jfokus.se/jfokus/jvmtech.jsp 
<https://www.jfokus.se/jfokus/jvmtech.jsp>

/M

/M

> On 19 Nov 2015, at 17:17, Marcus Lagergren  wrote:
> 
> And all talks have now been finalized: 
> https://www.jfokus.se/jfokus/jvmtech.jsp
> 
> A VM tech day without Martin Thompson is no VM tech day!
> 
> Regards
> Marcus
> 
>> On 11 Nov 2015, at 09:35, Marcus Lagergren  wrote:
>> 
>> Greetings community members!
>> 
>> I am coordinator for the JFokus VM Tech Day at the JFokus conference in 
>> February 2016. This is the second year running we have this event, and it 
>> was a great success last year. This year we have received significantly more 
>> contributions, and the hardest part was sifting through all quality material 
>> that we were given.
>> 
>> We are in the process of finalizing the speaker list, but 5 out of 6 slots 
>> are now filled and the current agenda looks like this: 
>> https://www.jfokus.se/jfokus/jvmtech.jsp
>> 
>> This year, Brian Goetz, Java Language Architect from Oracle opens the tech 
>> day, and talks about project Valhalla and how the OpenJDK is getting there.
>> 
>> Brian is followed by Charlie Gracie, IBM, who will cover what is some of the 
>> most exciting news in the runtime world for a very long time: The open 
>> sourcing of the J9 JVM and its APIs, and example applications in the dynamic 
>> language space.
>> 
>> We are also proud (as always) to host the formidable Mr. Aleksey Shipilev, 
>> performance czar extraordinare, always balancing on the fine line between 
>> brilliant and crazy. Aleksey's presentation is about String compaction, and 
>> String optimisations with invokedynamic in Java 9. Hopefully we have room 
>> for him at the ordinary JFokus conference as well, as the man spouts 
>> excellent tech presentations like a fountain.
>> 
>> Charlie Nutter also joins us to discuss JRuby 9000, which was released this 
>> summer, and about using the JVM as a platform for multi language development.
>> 
>> Paul Sandoz, a man who can do anything from REST services down to bare 
>> silicone magic in his job, will tell us about how VarHandles are implemented 
>> in the JVM, performance aspects and why no one should miss sun.misc.Unsafe.
>> 
>> Our sixth and final speaker slot is being allocated real soon now. Watch 
>> this space.
>> 
>> As usual there is time allocated for breakout sessions, improvised 
>> unscheduled lightning talks and discussions / Q&A.
>> 
>> Join the best VM internals conference initiative since JVMLS, and the first 
>> of its kind in the old world.
>> 
>> Regards
>> Marcus Lagergren
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: JFokus VM Tech Day 2016

[Marcus Lagergren]

And all talks have now been finalized: https://www.jfokus.se/jfokus/jvmtech.jsp

A VM tech day without Martin Thompson is no VM tech day!

Regards
Marcus

> On 11 Nov 2015, at 09:35, Marcus Lagergren  wrote:
> 
> Greetings community members!
> 
> I am coordinator for the JFokus VM Tech Day at the JFokus conference in 
> February 2016. This is the second year running we have this event, and it was 
> a great success last year. This year we have received significantly more 
> contributions, and the hardest part was sifting through all quality material 
> that we were given.
> 
> We are in the process of finalizing the speaker list, but 5 out of 6 slots 
> are now filled and the current agenda looks like this: 
> https://www.jfokus.se/jfokus/jvmtech.jsp
> 
> This year, Brian Goetz, Java Language Architect from Oracle opens the tech 
> day, and talks about project Valhalla and how the OpenJDK is getting there.
> 
> Brian is followed by Charlie Gracie, IBM, who will cover what is some of the 
> most exciting news in the runtime world for a very long time: The open 
> sourcing of the J9 JVM and its APIs, and example applications in the dynamic 
> language space.
> 
> We are also proud (as always) to host the formidable Mr. Aleksey Shipilev, 
> performance czar extraordinare, always balancing on the fine line between 
> brilliant and crazy. Aleksey's presentation is about String compaction, and 
> String optimisations with invokedynamic in Java 9. Hopefully we have room for 
> him at the ordinary JFokus conference as well, as the man spouts excellent 
> tech presentations like a fountain.
> 
> Charlie Nutter also joins us to discuss JRuby 9000, which was released this 
> summer, and about using the JVM as a platform for multi language development.
> 
> Paul Sandoz, a man who can do anything from REST services down to bare 
> silicone magic in his job, will tell us about how VarHandles are implemented 
> in the JVM, performance aspects and why no one should miss sun.misc.Unsafe.
> 
> Our sixth and final speaker slot is being allocated real soon now. Watch this 
> space.
> 
> As usual there is time allocated for breakout sessions, improvised 
> unscheduled lightning talks and discussions / Q&A.
> 
> Join the best VM internals conference initiative since JVMLS, and the first 
> of its kind in the old world.
> 
> Regards
> Marcus Lagergren
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: JFokus VM Tech Day 2016

[Marcus Lagergren]

D’oh. :-)

> On 12 Nov 2015, at 02:37, John Rose  wrote:
> 
> On Nov 11, 2015, at 12:35 AM, Marcus Lagergren  <mailto:mar...@lagergren.net>> wrote:
>> 
>> bare silicone magic
> 
> That extra E moves the venue from Santa Clara to Las Vegas.
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

JFokus VM Tech Day 2016

[Marcus Lagergren]

Greetings community members!

I am coordinator for the JFokus VM Tech Day at the JFokus conference in 
February 2016. This is the second year running we have this event, and it was a 
great success last year. This year we have received significantly more 
contributions, and the hardest part was sifting through all quality material 
that we were given.

We are in the process of finalizing the speaker list, but 5 out of 6 slots are 
now filled and the current agenda looks like this: 
https://www.jfokus.se/jfokus/jvmtech.jsp

This year, Brian Goetz, Java Language Architect from Oracle opens the tech day, 
and talks about project Valhalla and how the OpenJDK is getting there.

Brian is followed by Charlie Gracie, IBM, who will cover what is some of the 
most exciting news in the runtime world for a very long time: The open sourcing 
of the J9 JVM and its APIs, and example applications in the dynamic language 
space.

We are also proud (as always) to host the formidable Mr. Aleksey Shipilev, 
performance czar extraordinare, always balancing on the fine line between 
brilliant and crazy. Aleksey's presentation is about String compaction, and 
String optimisations with invokedynamic in Java 9. Hopefully we have room for 
him at the ordinary JFokus conference as well, as the man spouts excellent tech 
presentations like a fountain.

Charlie Nutter also joins us to discuss JRuby 9000, which was released this 
summer, and about using the JVM as a platform for multi language development.

Paul Sandoz, a man who can do anything from REST services down to bare silicone 
magic in his job, will tell us about how VarHandles are implemented in the JVM, 
performance aspects and why no one should miss sun.misc.Unsafe.

Our sixth and final speaker slot is being allocated real soon now. Watch this 
space.

As usual there is time allocated for breakout sessions, improvised unscheduled 
lightning talks and discussions / Q&A.

Join the best VM internals conference initiative since JVMLS, and the first of 
its kind in the old world.

Regards
Marcus Lagergren



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: What can we improve in JSR292 for Java 9?

[Marcus Lagergren]

At the VM language summit at JFokus 2015, we discussed having ways to get new 
dynamic language functions into the JVM without having to resort to generating 
a class wrapping their byte code. A class is currently the smallest possible 
compilation unit for the JVM, and its installation carries various overheads. 
Installing a non-anonymous class, as a lot of our classes need to be, for 
security reasons, also involve synchronizing on the system dictionary, and it 
seems that runtime has just given up on fixing that particular bottleneck [1] 
(I don’t agree at all with the conclusions in the CR). 

Currently, in Nashorn, whenever we regenerate a method due to a failed 
assumption or type specialization, we need to generate a new byte code method, 
wrap it in a synthetic class created for just that purpose, and then installing 
the class.

When John and Vladimir were over in Stockholm we discussed a “magic” combinator 
that basically would allow you to create your own collection of MethodHandles 
for code versions of a callsite. Combined with constant pool indexes it would 
allow code installation without going through classes. New could would mean 
adding a {MethodHandle, ConstantPoolData} tuple to a particular callsite’s 
representation.

/M

[1] https://bugs.openjdk.java.net/browse/JDK-8046708
 
> On 26 Feb 2015, at 13:42, MacGregor, Duncan (GE Energy Management) 
>  wrote:
> 
> MH.spreadArguments would certainly be useful from my point of view. We
> have many cases where we need to take a trailing argument array and turn
> it into some arguments, and array contain the remainder. This involves a
> depressing amount of shuffling at the moment, and should be better.
> 
> On 26/02/2015 02:29, "John Rose"  wrote:
> 
>> On Feb 25, 2015, at 4:02 PM, Charles Oliver Nutter 
>> wrote:
>>> 
>>> After talking with folks at the Jfokus VM Summit, it seems like
>>> there's a number of nice-to-have and a few need-to-have features we'd
>>> like to see get into java.lang.invoke. Vladimir suggested I start a
>>> thread on these features.
>>> 
>>> A few from me:
>>> 
>>> * A loop handle :-)
>>> 
>>> Given a body and a test, run the body until the test is false. I'm
>>> guessing there's a good reason we don't have this already.
>> 
>> A few reasons:   1. You can code your own easily.
>> 2. There's no One True Loop the way there is a One True If.
>> The "run until test is false" model assumes all the real work is
>> done with side-effects, which are off-center from the MH model.
>> 3. A really clean looping mechanism probably needs a sprinkle
>> of tail call optimization.
>> 
>> I'm not saying that loops should never have side effects, but I
>> am saying that a loop mechanism should not mandate them.
>> 
>> Maybe this is general enough:
>> 
>>   MHs.loop(init, predicate, body)(*a)
>>   => { let i = init(*a); while (predicate(i, *a)) { i = body(i, *a); }
>> return i; }
>> 
>> ...where the type of i depends on init, and if init returns void then you
>> have a classic side-effect-only loop.
>> 
>>> * try/finally as a core atom of MethodHandles API.
>>> 
>>> Libraries like invokebinder provide a shortcut API To generating the
>>> large tree of handles needed for try/finally, but the JVM may not be
>>> able to optimize that tree as well as a purpose-built adapter.
>> 
>> I agree there.  We should put this in.
>> 
>>  MHs.tryFinally(target, cleanup)(*a)
>>=> { try { return target(*a); } finally { cleanup(*a); } }
>> 
>> (Even here there are non-universalities; what if the cleanup
>> wants to see the return value and/or the thrown exception?
>> Should it take those as one or two leading arguments?)
>> 
>>> * Argument grouping operations in the middle of the argument list.
>>> 
>>> JRuby has many signatures that vararg somewhere other than the end of
>>> the argument list, and the juggling required to do that logic in
>>> handles is complex: shift to-be-boxed args to end, box them, shift box
>>> back.
>> 
>> We now have MHs.collectArguments.  Do you want MHs.spreadArguments
>> to reverse the effect?  Or is there something else I'm missing?
>> 
>>> Another point about these more complicated forms: they're ESPECIALLY
>>> slow early in execution, before LFs have been compiled to bytecode.
>>> 
>>> * Implementation-specific inspection API.
>>> 
>>> I know there are different ways to express a MH tree on different JVMs
>>> (e.g. J9) but it would still be a big help for me if there were a good
>>> way to get some debug-time structural information about a handle I'm
>>> using. Hidden API would be ok if it's not too hidden :-)
>> 
>> Idea of the day:  An ASM-like library for method handles.
>> Make a MethodHandleReader which can run a visitor over the MH.
>> The ops of the visitor would be a selection of public MH operations
>> like filter, collect, spread, lookup, etc.
>> Also ASM-like, the library would have a MethodHandleWriter
>> would could be hooked up with the reader to make filters.
>> 
>> ‹ John
>> _

Re: JFokus 2015 - the VM Tech Day

[Marcus Lagergren]

Btw,

I have a few 50% discounts left for the VM tech day. If you are interested, 
please e-mail me directly!

/Marcus

> On 19 Jan 2015, at 10:58, Marcus Lagergren  
> wrote:
> 
> And to further clarify things - you can attend _only_ the VM Tech day / tech 
> summit, should you so desire, and skip the rest of the JFokus conference. 
> (What a strange thing to do, given the quality of JFokus, but I can’t be the 
> one questioning your priorities here)
> 
> (http://www.jfokus.se/jfokus/register.jsp 
> <http://www.jfokus.se/jfokus/register.jsp>)
> 
> /M
> 
>> On 18 Jan 2015, at 22:54, Marcus Lagergren > <mailto:marcus.lagerg...@oracle.com>> wrote:
>> 
>> Greetings community members!
>> 
>> Here is something that I'm sure you'll find interesting.
>> 
>> I want to advertise the upcoming "VM tech day” event, scheduled to
>> take place February 2, 2015 at the JFokus conference in
>> Stockholm. Sorry I am on a bit of a short notice here, but finalizing
>> the speaker list took us a bit more time than expected.
>> 
>> The VM tech day is a mini-track that runs the first day of the JFokus
>> conference. This is its schedule: 
>> https://www.jfokus.se/jfokus/jvmtech.jsp 
>> <https://www.jfokus.se/jfokus/jvmtech.jsp>
>> 
>> After some rather challenging months of jigsaw puzzles, it is with
>> great pleasure that I can announce that our speaker line up is now
>> complete - and it is great indeed! We are talking 100% gurus,
>> prophets, ninjas, rock stars, and all other similar terms that
>> normally gets your resume binned if it passes my desk. But in this
>> case the labels are true. We have strictly top names from both the
>> commercial world and from academia ready to take you on a great
>> ride.
>> 
>> So what is the VM tech day? For those of you familiar with the JVM
>> Language Summit (JVMLS) that usually takes place in Santa Clara in
>> the summers, the format is similar. It’s the usual deal: anyone
>> morbidly interested in runtime internals, code generation, polyglot
>> programming and the complexities of language implementation, should
>> find a veritable gold mine of stimulating conversation and knowledge
>> transfer here. What is different from a typical JVMLS (except for the
>> shorter duration), is that we have widened the scope a bit to include
>> several runtimes, language implementation issues and polyglot
>> problems.
>> 
>> There will be six scheduled sessions and plenty of time for breakouts
>> and discussions. We will also heavily encourage audience interaction
>> and participation.
>> 
>> The JFokus VM tech day is opened by John Rose. I am sure John needs 
>> no introduction to the subscribers of this list. With advanced OpenJDK
>> projects like Valhalla and Panama booting up, John will discuss what
>> the JVM has in store for the future. 
>> 
>> Other speakers include the tireless Charlie Nutter from Red Hat, the
>> formidable Remi Forax, the brilliant Vyacheslav Egorov of Google v8
>> fame, the esteemed Dan Heidinga from IBM and the good looking Attila
>> Szegedi from Oracle.
>> 
>> We also have plenty of non-speaking celebrity participants in the
>> audience, for example Fredrik Öhrström: invokedynamic specification 
>> wizard extraordinaire and architect behind the new OpenJDK build
>> system. Stop by and get autographs ;)
>> 
>> Thusly: if you are attending JFokus, or if you are making up your mind
>> about attending it right now, the VM tech summit is definitely
>> something anyone subscribing to mlvm-dev wouldn't want to miss. The
>> cross-platform/cross-technology/cross-company focus that we have tried
>> very hard to create will without a doubt be ultra stimulating. Of that
>> you can be sure.
>> 
>> Please help us spread the word in whatever forums you deem
>> appropriate! Talk to you friends! Tweet links to this post! Yell from
>> your cubicle soap boxes across the neverending seas of fluorescent
>> lights!
>> 
>> Any further questions you may have about the event, not answered by
>> the web pages, can be directed either to me (@lagergren) or Mattias 
>> Karlsson (@matkar) or as replies to this e-mail thread.
>> 
>> On behalf of JFokus / VM Tech Day 2015
>> Marcus Lagergren
>> Master of ceremonies (or something)
>> 
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: JFokus 2015 - the VM Tech Day

[Marcus Lagergren]

And to further clarify things - you can attend _only_ the VM Tech day / tech 
summit, should you so desire, and skip the rest of the JFokus conference. (What 
a strange thing to do, given the quality of JFokus, but I can’t be the one 
questioning your priorities here)

(http://www.jfokus.se/jfokus/register.jsp 
<http://www.jfokus.se/jfokus/register.jsp>)

/M

> On 18 Jan 2015, at 22:54, Marcus Lagergren  
> wrote:
> 
> Greetings community members!
> 
> Here is something that I'm sure you'll find interesting.
> 
> I want to advertise the upcoming "VM tech day” event, scheduled to
> take place February 2, 2015 at the JFokus conference in
> Stockholm. Sorry I am on a bit of a short notice here, but finalizing
> the speaker list took us a bit more time than expected.
> 
> The VM tech day is a mini-track that runs the first day of the JFokus
> conference. This is its schedule: 
> https://www.jfokus.se/jfokus/jvmtech.jsp
> 
> After some rather challenging months of jigsaw puzzles, it is with
> great pleasure that I can announce that our speaker line up is now
> complete - and it is great indeed! We are talking 100% gurus,
> prophets, ninjas, rock stars, and all other similar terms that
> normally gets your resume binned if it passes my desk. But in this
> case the labels are true. We have strictly top names from both the
> commercial world and from academia ready to take you on a great
> ride.
> 
> So what is the VM tech day? For those of you familiar with the JVM
> Language Summit (JVMLS) that usually takes place in Santa Clara in
> the summers, the format is similar. It’s the usual deal: anyone
> morbidly interested in runtime internals, code generation, polyglot
> programming and the complexities of language implementation, should
> find a veritable gold mine of stimulating conversation and knowledge
> transfer here. What is different from a typical JVMLS (except for the
> shorter duration), is that we have widened the scope a bit to include
> several runtimes, language implementation issues and polyglot
> problems.
> 
> There will be six scheduled sessions and plenty of time for breakouts
> and discussions. We will also heavily encourage audience interaction
> and participation.
> 
> The JFokus VM tech day is opened by John Rose. I am sure John needs 
> no introduction to the subscribers of this list. With advanced OpenJDK
> projects like Valhalla and Panama booting up, John will discuss what
> the JVM has in store for the future. 
> 
> Other speakers include the tireless Charlie Nutter from Red Hat, the
> formidable Remi Forax, the brilliant Vyacheslav Egorov of Google v8
> fame, the esteemed Dan Heidinga from IBM and the good looking Attila
> Szegedi from Oracle.
> 
> We also have plenty of non-speaking celebrity participants in the
> audience, for example Fredrik Öhrström: invokedynamic specification 
> wizard extraordinaire and architect behind the new OpenJDK build
> system. Stop by and get autographs ;)
> 
> Thusly: if you are attending JFokus, or if you are making up your mind
> about attending it right now, the VM tech summit is definitely
> something anyone subscribing to mlvm-dev wouldn't want to miss. The
> cross-platform/cross-technology/cross-company focus that we have tried
> very hard to create will without a doubt be ultra stimulating. Of that
> you can be sure.
> 
> Please help us spread the word in whatever forums you deem
> appropriate! Talk to you friends! Tweet links to this post! Yell from
> your cubicle soap boxes across the neverending seas of fluorescent
> lights!
> 
> Any further questions you may have about the event, not answered by
> the web pages, can be directed either to me (@lagergren) or Mattias 
> Karlsson (@matkar) or as replies to this e-mail thread.
> 
> On behalf of JFokus / VM Tech Day 2015
> Marcus Lagergren
> Master of ceremonies (or something)
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

JFokus 2015 - the VM Tech Day

[Marcus Lagergren]

Greetings community members!

Here is something that I'm sure you'll find interesting.

I want to advertise the upcoming "VM tech day” event, scheduled to
take place February 2, 2015 at the JFokus conference in
Stockholm. Sorry I am on a bit of a short notice here, but finalizing
the speaker list took us a bit more time than expected.

The VM tech day is a mini-track that runs the first day of the JFokus
conference. This is its schedule: 
https://www.jfokus.se/jfokus/jvmtech.jsp

After some rather challenging months of jigsaw puzzles, it is with
great pleasure that I can announce that our speaker line up is now
complete - and it is great indeed! We are talking 100% gurus,
prophets, ninjas, rock stars, and all other similar terms that
normally gets your resume binned if it passes my desk. But in this
case the labels are true. We have strictly top names from both the
commercial world and from academia ready to take you on a great
ride.

So what is the VM tech day? For those of you familiar with the JVM
Language Summit (JVMLS) that usually takes place in Santa Clara in
the summers, the format is similar. It’s the usual deal: anyone
morbidly interested in runtime internals, code generation, polyglot
programming and the complexities of language implementation, should
find a veritable gold mine of stimulating conversation and knowledge
transfer here. What is different from a typical JVMLS (except for the
shorter duration), is that we have widened the scope a bit to include
several runtimes, language implementation issues and polyglot
problems.

There will be six scheduled sessions and plenty of time for breakouts
and discussions. We will also heavily encourage audience interaction
and participation.

The JFokus VM tech day is opened by John Rose. I am sure John needs 
no introduction to the subscribers of this list. With advanced OpenJDK
projects like Valhalla and Panama booting up, John will discuss what
the JVM has in store for the future. 

Other speakers include the tireless Charlie Nutter from Red Hat, the
formidable Remi Forax, the brilliant Vyacheslav Egorov of Google v8
fame, the esteemed Dan Heidinga from IBM and the good looking Attila
Szegedi from Oracle.

We also have plenty of non-speaking celebrity participants in the
audience, for example Fredrik Öhrström: invokedynamic specification 
wizard extraordinaire and architect behind the new OpenJDK build
system. Stop by and get autographs ;)

Thusly: if you are attending JFokus, or if you are making up your mind
about attending it right now, the VM tech summit is definitely
something anyone subscribing to mlvm-dev wouldn't want to miss. The
cross-platform/cross-technology/cross-company focus that we have tried
very hard to create will without a doubt be ultra stimulating. Of that
you can be sure.

Please help us spread the word in whatever forums you deem
appropriate! Talk to you friends! Tweet links to this post! Yell from
your cubicle soap boxes across the neverending seas of fluorescent
lights!

Any further questions you may have about the event, not answered by
the web pages, can be directed either to me (@lagergren) or Mattias 
Karlsson (@matkar) or as replies to this e-mail thread.

On behalf of JFokus / VM Tech Day 2015
Marcus Lagergren
Master of ceremonies (or something)

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Invokedynamic and recursive method call

[Marcus Lagergren]

7u40 is when the native invoke dynamic implementation was replaced with Lambda 
Forms :-/

/M

> On 07 Jan 2015, at 17:13, Remi Forax  wrote:
> 
> 
> On 01/07/2015 10:43 AM, Marcus Lagergren wrote:
>> Remi, I tried to reproduce your problem with jdk9 b44. It runs decently fast.
> 
> yes, nashorn is fast enough but it can be faster if the JIT was not doing 
> something stupid.
> 
> When the VM inline fibo, because fibo is recursive, the recursive call is 
> inlined only once,
> so the call at depth=2 can not be inlined but should be a classical direct 
> call.
> 
> But if fibo is called through an invokedynamic, instead of emitting a direct 
> call to fibo,
> the JIT generates a code that push the method handle on stack and execute it
> like if the metod handle was not constant
> (the method handle is constant because the call at depth=1 is inlined !).
> 
>> When did it start to regress?
> 
> jdk7u40, i believe.
> 
> I've created a jar containing some handwritten bytecodes with no dependency 
> to reproduce the issue easily:
>  https://github.com/forax/vmboiler/blob/master/test7/fibo7.jar 
> <https://github.com/forax/vmboiler/blob/master/test7/fibo7.jar>
> 
> [forax@localhost test7]$ time /usr/jdk/jdk1.9.0/bin/java -cp fibo7.jar 
> FiboSample
> 1836311903
> 
> real0m6.653s
> user0m6.729s
> sys0m0.019s
> [forax@localhost test7]$ time /usr/jdk/jdk1.8.0_25/bin/java -cp fibo7.jar 
> FiboSample
> 1836311903
> 
> real0m6.572s
> user0m6.591s
> sys0m0.019s
> [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_71/bin/java -cp fibo7.jar 
> FiboSample
> 1836311903
> 
> real0m6.373s
> user0m6.396s
> sys0m0.016s
> [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_25/bin/java -cp fibo7.jar 
> FiboSample
> 1836311903
> 
> real0m4.847s
> user0m4.832s
> sys0m0.019s
> 
> as you can see, it was faster with a JDK before jdk7u40.
> 
>> 
>> Regards
>> Marcus
> 
> cheers,
> Rémi
> 
>> 
>>> On 30 Dec 2014, at 20:48, Remi Forax  wrote:
>>> 
>>> Hi guys,
>>> I've found a bug in the interaction between the lambda form and inlining 
>>> algorithm,
>>> basically if the inlining heuristic bailout because the method is recursive 
>>> and already inlined once,
>>> instead to emit a code to do a direct call, it revert to do call to 
>>> linkStatic with the method
>>> as MemberName.
>>> 
>>> I think it's a regression because before the introduction of lambda forms,
>>> I'm pretty sure that the JIT was emitting a direct call.
>>> 
>>> Step to reproduce with nashorn, run this JavaScript code
>>> function fibo(n) {
>>>  return (n < 2)? 1: fibo(n - 1) + fibo(n - 2)
>>> }
>>> 
>>> print(fibo(45))
>>> 
>>> like this:
>>>  /usr/jdk/jdk1.9.0/bin/jjs -J-XX:+UnlockDiagnosticVMOptions 
>>> -J-XX:+PrintAssembly fibo.js > log.txt
>>> 
>>> look for a method 'fibo' from the tail of the log, you will find something 
>>> like this:
>>> 
>>>  0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a 
>>> 'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo' 
>>> '(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in 
>>> 'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}
>>>  0x7f97e4b47449: xchg   %ax,%ax
>>>  0x7f97e4b4744b: callq  0x7f97dd0446e0
>>> 
>>> I hope this can be fixed. My demonstration that I can have fibo written 
>>> with a dynamic language
>>> that run as fast as written in Java doesn't work anymore :(
>>> 
>>> cheers,
>>> Rémi
>>> 
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net <mailto:mlvm-dev@openjdk.java.net>
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev 
> <http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Invokedynamic and recursive method call

[Marcus Lagergren]

Remi, I tried to reproduce your problem with jdk9 b44. It runs decently fast. 
When did it start to regress?

Regards
Marcus

> On 30 Dec 2014, at 20:48, Remi Forax  wrote:
> 
> Hi guys,
> I've found a bug in the interaction between the lambda form and inlining 
> algorithm,
> basically if the inlining heuristic bailout because the method is recursive 
> and already inlined once,
> instead to emit a code to do a direct call, it revert to do call to 
> linkStatic with the method
> as MemberName.
> 
> I think it's a regression because before the introduction of lambda forms,
> I'm pretty sure that the JIT was emitting a direct call.
> 
> Step to reproduce with nashorn, run this JavaScript code
> function fibo(n) {
>  return (n < 2)? 1: fibo(n - 1) + fibo(n - 2)
> }
> 
> print(fibo(45))
> 
> like this:
>  /usr/jdk/jdk1.9.0/bin/jjs -J-XX:+UnlockDiagnosticVMOptions 
> -J-XX:+PrintAssembly fibo.js > log.txt
> 
> look for a method 'fibo' from the tail of the log, you will find something 
> like this:
> 
>  0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a 
> 'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo' 
> '(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in 
> 'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}
>  0x7f97e4b47449: xchg   %ax,%ax
>  0x7f97e4b4744b: callq  0x7f97dd0446e0
> 
> I hope this can be fixed. My demonstration that I can have fibo written with 
> a dynamic language
> that run as fast as written in Java doesn't work anymore :(
> 
> cheers,
> Rémi
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: MemberName$Factory.resolve() and the Eclipse debugger.

[Marcus Lagergren]

Nicely done, Duncan. Do you have a link to the issue report?

Regards
Marcus

> On 03 Nov 2014, at 16:48, MacGregor, Duncan (GE Energy Management) 
>  wrote:
> 
> I’ve reported an Eclipse bug. Doesn’t look like their debugger has ever
> done quite the right thing, unless the behaviour of the JVM has changed
> significantly.
> 
> On 03/11/2014 15:33, "Christian Thalinger"
>  wrote:
> 
>> Interesting.  Thanks for digging deep.
>> 
>>> On Oct 31, 2014, at 8:36 AM, MacGregor, Duncan (GE Energy Management)
>>>  wrote:
>>> 
>>> Okay, I now know why the JVM is stuck for so long, just not why Eclipse
>>> is
>>> doing what it does.
>>> 
>>> At certain points during the loading of our application Eclipse will
>>> make
>>> a large number (upto 1) jdwp classesForSignature requests, each of
>>> which causes the jdwp lib to trawl over a large number of classes
>>> (several
>>> 10s of thousands), resulting in upto a couple hundred million jvmti
>>> GetClassSignature calls, and is particularly pointless because it fails
>>> to
>>> find any of these classes.
>>> 
>>> That last bit gave me a clue. These large numbers of classesForSignature
>>> requests occur when classes have been GCed, and a request is being
>>> issued
>>> for every single class that has been successfully Gced. Since we¹re
>>> careful to ensure that all the code we dynamically execute at startup is
>>> done in temporary class loaders so that the everything can be Gced away,
>>> and since variance LF stuff can also be Gced, the problem is much worse
>>> than it would be in other applications.
>>> 
>>> It¹s really bad in earlier 8 updates without the LF editor work because
>>> there¹s more classes and more getting Gced, so I¹ve seen 3 minute long
>>> pauses with that version.
>>> 
>>> I guess this should be reported as a bug to the Eclipse debug team, but
>>> I
>>> wonder if classesForSignature can¹t be made faster in some way.
>>> 
>>> Regards, Duncan.
>>> 
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: [9] RFR (XS): 8060483: NPE with explicitCastArguments unboxing null

[Marcus Lagergren]

+1 for me. I assume that Wrapper.java is only reformatting. It looks like it.

Regards
Marcus

On 15 Oct 2014, at 14:12, Vladimir Ivanov  wrote:

> http://cr.openjdk.java.net/~vlivanov/8060483/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8060483
> 
> Recent changes broke MHs.explicitCastArguments for null values when unboxing 
> taking place.
> 
> The fix corrects the equivalence check for MHs.eCA & MH.asType() in 
> MT.explicitCastEquivalentToAsType().
> 
> Also, will file a followup enhancement request to improve test coverage for 
> MHs.eCA method.
> 
> Testing: regression test, jck (api/java_lang/invoke), jdk/java/lang/invoke
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

[Marcus Lagergren]

Totally agree on that bytecode based metrics are evil.

On 05 Sep 2014, at 14:32, Thomas Wuerthinger  
wrote:

> This is why Graal’s inlining heuristics are not based on the number of 
> bytecodes, but the complexity of the compiler graph after applying 
> canonicalisation. Adding asserts to the bytecodes should not influence peak 
> performance when they are disabled. Same for expressing the same logic with a 
> different number of bytecodes.
> 
> - thomas
> 
> On 05 Sep 2014, at 08:59, Remi Forax  wrote:
> 
>> 
>> On 09/03/2014 07:46 PM, John Rose wrote:
>>> On Sep 3, 2014, at 10:35 AM, Mark Roos  wrote:
>>> 
 From Morris
 
All that assert laden code is nice to see.
 
 I just finished watching a video from Doug Lea where he mentioned that 
 having asserts can
 inhibit inlining due to the additional byte codes.  So he sadly does not 
 use them due to
 performance issues.
 
 Does anyone have any insights on this?
>>> Yep.
>>> 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028450.html
>>> https://bugs.openjdk.java.net/browse/JDK-6316156
>> 
>> yes, sadly, it's sometimes a real problem, here is a thread on core-lib [1] 
>> about removing an assert in Integer.valueOf that allow JDart to have 
>> acceptable perf.
>> 
>>> 
>>> — John
>> 
>> Rémi
>> 
>> [1] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/010007.html
>> 
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: [9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods

[Marcus Lagergren]

To the style rant, I mean.

On 05 Sep 2014, at 13:40, Marcus Lagergren  wrote:

> +1
> 
> On 05 Sep 2014, at 12:46, Aleksey Shipilev  
> wrote:
> 
>> On 09/05/2014 12:09 PM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8057654
>> 
>> Random style rant of the week, not particularly about this concrete
>> patch. Can we please try to systematically use more
>> readable/robust/secure idioms? E.g.:
>> 
>> a) Always have curly braces around the blocks?
>> 
>>if (ok && ...) {
>>  ok = false;
>>}
>>if (!ok) {
>>  throw misMatchedTypes(...);
>>}
>>return rtype;
>> 
>>  vs.
>> 
>>if (ok && ...)
>>  ok = false;
>>if (!ok)
>>  throw misMatchedTypes(...);
>>return rtype;
>> 
>>  Apple's "goto fail;" bug, anyone?
>> 
>> b) Have only a single initialization per line?
>> 
>>  boolean match = true;
>>  boolean fail = false;
>>  vs.
>>  boolean match = true, fail = false;
>> 
>> c) Always have parentheses in ternary operators predicates?
>> 
>>  int foldVals = (rtype == void.class) ? 0 : 1;
>>   vs.
>>  int foldVals = rtype == void.class ? 0 : 1;
>> 
>> Thanks,
>> -Aleksey.
>> 
>> 
> 

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: [9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods

[Marcus Lagergren]

+1

On 05 Sep 2014, at 12:46, Aleksey Shipilev  wrote:

> On 09/05/2014 12:09 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8057654
> 
> Random style rant of the week, not particularly about this concrete
> patch. Can we please try to systematically use more
> readable/robust/secure idioms? E.g.:
> 
> a) Always have curly braces around the blocks?
> 
> if (ok && ...) {
>   ok = false;
> }
> if (!ok) {
>   throw misMatchedTypes(...);
> }
> return rtype;
> 
>   vs.
> 
> if (ok && ...)
>   ok = false;
> if (!ok)
>   throw misMatchedTypes(...);
> return rtype;
> 
>   Apple's "goto fail;" bug, anyone?
> 
> b) Have only a single initialization per line?
> 
>   boolean match = true;
>   boolean fail = false;
>   vs.
>   boolean match = true, fail = false;
> 
> c) Always have parentheses in ternary operators predicates?
> 
>   int foldVals = (rtype == void.class) ? 0 : 1;
>vs.
>   int foldVals = rtype == void.class ? 0 : 1;
> 
> Thanks,
> -Aleksey.
> 
> 

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: The Great Startup Problem

[Marcus Lagergren]

Ah yes- this was a bad example given that we cache the lambda forms. Sorry. I 
do see lambda form execution time for other things that aren’t inlined, though. 
Let me get back to you with profiles.

When it comes to generating call site specific typed invokers as discussed in 
this thread, I think that is definitely going to be necessary. Perhaps Attila 
can comment here. 

/M

On 01 Sep 2014, at 13:03, Vladimir Ivanov  wrote:

> Marcus,
> 
>> And lambdaform code that never really has a chance to be properly optimized 
>> - sometimes just simply because the JIT stops inlining, or sometimes because 
>> java.lang.invoke is full of boxing and arraycopies that simple don’t go away.
> If you have any info about any of those problems, please, file a bug/let me 
> know. I'll be happy to fix them.
> 
>> Sergey Kuksenko had a very interesting performance analysis presentation at 
>> JVMLS this year where ~41% of his runtime for Nashorn with octane.box2d was 
>> unlined lambda forms.
> I already told you in private, but just to let others know.
> The reason why there's an uninlined LambdaForm call in Box2D is because 
> Nashorn does MH caching itself (see [1]).
> 
> HotSpot can't see through the cache and it doesn't do value profiling of 
> receiver for MethodHandle.invoke*(), so inlining fails.
> 
> Roland experimented with receiver profiling for MethodHandle.invoke* support, 
> but I'm not aware about any plans to integrate it into the product.
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] nashorn.internal.runtime.UserAccessorProperty.userAccessorGetter
>nashorn.internal.runtime.UserAccessorProperty.userAccessorSetter
> 
> http://hg.openjdk.java.net/jdk9/jdk9/nashorn/file/adc2b63e654a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java#l276
> 
> And this is basically just the mechanisms pushing parameters and applying 
> filters around the callsite. Seems like lambdaforms have to be treated 
> specially (or rather indy callsites) by the JIT.
> 
> 
>> 
>> One solution that was proposed for 8u40 was JEP210 (lambda form caching), 
>> which does indeed keep footprint down, but performance suffers mightily 
>> since the same lambdaform snippet kan now be used at two completely 
>> different call sites, which brings us cache pollution. Vladimir is on 
>> vacation, but even though this brings metaspace down, I don’t think 
>> performance is back yet.
>> 
>> Even if everything inlinines correctly and deeply (which doesn’t happen all 
>> he time in C2 for long chains), we still have the problem of holding on to 
>> this synthetic bytecode/metaspace constructs for the LambdaForms. We really 
>> don’t want to have all this bookkeeping around something that can be as 
>> simple as permuting a couple of parameters (yes, it can be more complex, 
>> same argument applies)
>> 
>> LambdaForms were most likely introduced as a platform independent way of 
>> implementing methodhandle combinators in 8, because the 7 native 
>> implementation was not very stable, but it was probably a mistake to add 
>> them as “real” classes instead of code snippets that can just be spliced in 
>> around the callsite. (I completely lack history here, so flame me if I am 
>> wrong)
>> 
>> For both JRuby and Nashorn in the indy world, starting up a process 
>> generates bytecode where say every 5th to 10th instruction is an indy. 
>> Lambda code is not that bad, but it can also look pretty hairy. Now, if 
>> runtime linkage for each of these callsites requires metaspace, hidden 
>> bytecode generation, anonymous internal classes and the rest of the 
>> combinatorial explosion Charlie describes, we are setting us up for really 
>> bad scalability on such an arena. And metaspace of course, goes through the 
>> roof. Custom runtime linkage is still slow, but at least it only happens 
>> once.We don’t want to keep adding even more overhead o that.
>> 
>> For 9, it seems that we need a way to implement an indy that doesn’t result 
>> in class generation and installation of anonymous runtime classes. Note that 
>> _class installation_ as such is also a large overhead in the JVM - even more 
>> so when we regenerate more code to get more optimal types. I think we need 
>> to move from separate classes to inlined code, or something that requires 
>> minimium bookkeeping. I think this may be subject to profile pollution as 
>> well, but I haven’t been able to get my head around the ramifications yet.
>> 
>> There are various problems here as well (for example, several of the 
>> java.lang.invoke combinators create boxing and arrays and do arraycopies), 
>> stuff that would needed to be optimized away, or it’ll punish any indy call. 
>> In such an environment we can cheat with annotations like 
>> @ExplodeThisArrayToLocals or @NoSafePoint or similar magic annotations, 
>> because after all we own the code we splice in. (Solving local escape 
>> analysis, which is really the problem in the generic form of callsite IR

Re: The Great Startup Problem

[Marcus Lagergren]

I think this is an excellent summary, John. 

I also think that a scary point Charlie and I were trying to make in this 
thread is that we have <= 12 months or so to slim down existing mechanisms to 
something that works with startup for the existing indy solutions before 9 is 
frozen. I think, given the time constraints, that there is no way doing this by 
NOT working with the current compiler infrastructure. We already had some nice 
ideas in Santa Clara this August.  I don’t think 12 months is enough replace 
our entire indy architecture with something else entirely, or even to decide 
what that would be. For the sake of this discussion I am ONLY wearing my 
“lambda forms scale poorly, we need to fix that for nine” hat, which is a very, 
very pragmatic hat indeed. I am ONLY wearing this hat. Again: ONLY THE 
PRAGMATIC HAT. It contains very little architectural vision. 

I’d totally welcome future dynamic language threads that discuss completely new 
architectures, but it would be good if we could split this thread in more then. 
I’m just trying to ship a product for Java 9 that works. While I am not PM, 12 
months is an incredibly short time to replace the entire world. I don’t think 
it has ever been done and I don’t think it CAN be done. Even if code exists. 
Sorry. Pragmatic hat.

Another point, that I know Charlie has brought up earlier, is that we also 
cannot abandon those who still target the JVM and seek value in a common 
platform. At least not before bytecode 2.0, whatever that may entail. 
Interesting discussion, but again - different thread I think. This means 
bytecode land. This means indy. 

So before we soar up into the cloud free architectural sky (in other threads), 
can we use this one to discuss things like local escape analysis around indys, 
maybe with cheating (knowing they are indys), local array explosion, indy 
callsite layout and by appropriating what we can of Fredrik Öhrström’s magic 
machine code hats? If this is not what you were after, Charlie, do tell me. I 
believe you were. 

I want make it absolutely clear, with no possibility of doubt, that I am merely 
pragmatic right now, which is all I feel I can find the time to be in the 
current timeframe. I need a near solution. Now. I am wearing blinkers. I am 
looking straight ahead. The cruel master sits heavy on my saddle with a 
backpack full of metaspace. I can’t, sadly, afford to live in any other world 
than this at the moment. Right now, I first want to get rid of lambda form 
scaling problems. Period. I am trying to ship product. After that we can 
discuss where our wonderful architectures will take us.

So if possible - let’s do one thing here: discuss what we can do for 9, in the 
time frame that is left, to make indys go faster for the use cases that have 
cropped up. With the current architecture. With lambda forms. With the nearly 
identical problems that both Charlie and we face. Let a thousand other threads 
start, discussing the rest, though. That is also great and exactly what this 
group is for, but I need some help with C1/C2 and invokedynamic at the moment! 
I need machine code rabbits! I think that machine code rabbits were also what 
Charlie asked for.

Regards
Marcus

(who is really happy to see MLVM-dev vibrant again, lately)

On 29 Aug 2014, at 05:48, John Rose  wrote:

> On Aug 22, 2014, at 1:08 PM, Charles Oliver Nutter  
> wrote:
> 
>> Marcus coaxed me into making a post about our indy issues. Our indy
>> issues mostly surround startup and warmup time, so I'm making this a
>> general post about startup and warmup.
> 
> This is a vigorous and interesting discussion.  I will make some piecemeal 
> replies to
> specific points, but first, as a HotSpot team member, I'll comment on the 
> startup
> problem and then set out our position and vision for indy and dynamic 
> languages.
> 
> Achilles had two heels, and so does Java:  Startup and warmup.  Many teams of 
> many
> people have worked on these issues for years, with hard-won progress.  
> Compared
> with C programs (say, "/bin/awk"), the JVM takes a long time to get going.
> 
> Fundamentally this comes from the decision to package programs as bytecodes
> (JARs, etc.) rather than machine instructions plus mappable data (dylibs, 
> etc.).
> As everyone on this list knows and appreciates, Java bytecodes are a portable,
> stable, and compact intermediate representation for both code and data 
> structure.
> You can do an amazing variety of great things with them, and there is no 
> credible
> proposal (IMO) to replace them wholesale with some other representation.
> 
> As an inherent property, bytecodes cannot be executed directly, requiring
> additional machinery to execute: an interpreter, JIT compiler, and/or AOT 
> engine.
> Making this machinery look small is an ongoing challenge for us JVM 
> implementors.
> I say "ongoing" (not just "historic") because software complexity scales up 
> with time.
> 
> Our basic move is organizing cold stuff dif

Re: The Great Startup Problem

[Marcus Lagergren]

Regarding indy dense code:

It is certainly a problem both for JRuby with indy and Nashorn with indy that 
indy scalability is so bad in 9 builds with the current JITs. I suspect that as 
Java 8 grows as a code base and as a language, it will turn into a problem with 
Java 8 lambdas too. Nashorn generates a lot more code to pick the correct time 
and generate faster code, this means a lot more indys. This means a lot more 
lambdaforms. This means a lot more metaspace. This means a lot longer warmup. 
And lambdaform code that never really has a chance to be properly optimized - 
sometimes just simply because the JIT stops inlining, or sometimes because 
java.lang.invoke is full of boxing and arraycopies that simple don’t go away.

As Charlie pointed out, an invokedynamic callsite is generated as a seperate 
method in a separate class (albeit anonymous), which eventually loads up the 
metaspace with tremendous amounts of stuff. Sergey Kuksenko had a very 
interesting performance analysis presentation at JVMLS this year where ~41% of 
his runtime for Nashorn with octane.box2d was unlined lambda forms. And this is 
basically just the mechanisms pushing parameters and applying filters around 
the callsite. Seems like lambdaforms have to be treated specially (or rather 
indy callsites) by the JIT.

One solution that was proposed for 8u40 was JEP210 (lambda form caching), which 
does indeed keep footprint down, but performance suffers mightily since the 
same lambdaform snippet kan now be used at two completely different call sites, 
which brings us cache pollution. Vladimir is on vacation, but even though this 
brings metaspace down, I don’t think performance is back yet.

Even if everything inlinines correctly and deeply (which doesn’t happen all he 
time in C2 for long chains), we still have the problem of holding on to this 
synthetic bytecode/metaspace constructs for the LambdaForms. We really don’t 
want to have all this bookkeeping around something that can be as simple as 
permuting a couple of parameters (yes, it can be more complex, same argument 
applies)

LambdaForms were most likely introduced as a platform independent way of 
implementing methodhandle combinators in 8, because the 7 native implementation 
was not very stable, but it was probably a mistake to add them as “real” 
classes instead of code snippets that can just be spliced in around the 
callsite. (I completely lack history here, so flame me if I am wrong)

For both JRuby and Nashorn in the indy world, starting up a process generates 
bytecode where say every 5th to 10th instruction is an indy. Lambda code is not 
that bad, but it can also look pretty hairy. Now, if runtime linkage for each 
of these callsites requires metaspace, hidden bytecode generation, anonymous 
internal classes and the rest of the combinatorial explosion Charlie describes, 
we are setting us up for really bad scalability on such an arena. And metaspace 
of course, goes through the roof. Custom runtime linkage is still slow, but at 
least it only happens once.We don’t want to keep adding even more overhead o 
that.

For 9, it seems that we need a way to implement an indy that doesn’t result in 
class generation and installation of anonymous runtime classes. Note that 
_class installation_ as such is also a large overhead in the JVM - even more so 
when we regenerate more code to get more optimal types. I think we need to move 
from separate classes to inlined code, or something that requires minimium 
bookkeeping. I think this may be subject to profile pollution as well, but I 
haven’t been able to get my head around the ramifications yet.

There are various problems here as well (for example, several of the 
java.lang.invoke combinators create boxing and arrays and do arraycopies), 
stuff that would needed to be optimized away, or it’ll punish any indy call. In 
such an environment we can cheat with annotations like 
@ExplodeThisArrayToLocals or @NoSafePoint or similar magic annotations, because 
after all we own the code we splice in. (Solving local escape analysis, which 
is really the problem in the generic form of callsite IR, has so far not been 
very successful in C2), but even if C2 is a little bit legacy, making things 
like this hard, we might still be able to cheat for the limited world/range 
that is an indy callsite and teach C2 some magic. Lots of early performance 
problems Attila and I had in Nashorn were from e.g. 
MethodHandles.catchExcetption, that had to be rewritten to avoid boxing, but 
I’m talking about a more generic mechanism than this.

Having said this, I don’t think that we can solve the indy scalability problems 
in the current jits, without getting away from the class generatation/bytecode 
spewing that results from an indy callsite being compiled. Caching lambda forms 
brings the memory footprint down, but I am already quite worried that it will 
get nowhere near the performance that is needed, due to profile pollution.

If 9 is a pla

Re: The Great Startup Problem

[Marcus Lagergren]

Hi Per!

This is mostly invokedynamic related. Basically, an indy callsite requires a 
lot of implicit class and byte code generation, that is the source of the 
overhead we are mostly discussing. While tiered compilation adds non 
determinism, it is usually (IMHO) bearable…

/M


 On 23 Aug 2014, at 21:45, Per Bothner  wrote:

> 
> 
> On 08/23/2014 12:25 PM, Per Bothner wrote:
>> On 08/22/2014 01:08 PM, Charles Oliver Nutter wrote:
>>> What are the rest of you doing to deal with these issues?
>> 
>> Start-up does not appear to a problem for Kawa:
> 
> I should mention I'm not using invokedynamic, and have no
> concrete plans to do so.  However, I am working on pattern-matching, which
> may make multi-methods more attractive, in which case invokedynamic
> may be more of a benefit.  InDy would probably also be helpful for arithmetic
> (though for performance-critical code it is better to make use of
> optional type specifiers and type inference)
> 
> I will be using MethodHandles extensively in a re-write of the
> "apply" mechanism that I'm working on.  This will replace the "switch"
> pattern I'm using, and should avoid the need for generating a 'ModuleBody'
> class in some cases.
> -- 
>   --Per Bothner
> p...@bothner.com   http://per.bothner.com/
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: The Great Startup Problem

[Marcus Lagergren]

I agree completely with Charlie’s assessment about Lambda Forms being a 
problematic mechanism for indy call site linking due to its 

* Lack of scalability (explosion of byte code)
* Metaspace usage

and everything else that has been described below.

I’m currently recovering after surgery and a bit disoriented and confused, but 
I’ll try to write a longer reply on Monday or Tuesday. 

This post illustrates perfectly to me why it’s important to replace of the 
LambdaForms as they are currently implemented with something else - probably 
even latest in the 9 timeframe. This may be a market window of opportunity that 
is slowly sliding from us. (PM and management might of course have things to 
say here, but for me this thing keeps bubbling up behind me as soon as I look 
away. It certainly has the last 12-18 months). 

We have identical issues with LambdaForms Nashorn. Some of them can to be 
solved with AOT, and have been in 8u20, (the second run of any Nashorn 
application can use a persistent code cache complete with optimizations and 
known types), but for the first run we have similar issues. Some of the warmup 
problem can be done by interpreting the JavaScript AST (we currently don’t do 
that) in a profiling pass, but once we lay out indys we are still going to have 
the scalability problem you described with just a lowered constant factor. (But 
who wants to write an interpreter on your interpreter and there’s debugging 
issues and security issues and such). Also - Interpreters are not particularly 
known to be fast either. We are exploring various other ways not to have to lay 
out so many indys at warmup, but I haven’t got enough on my feet to want to 
talk about it yet.

LambdaForm caching (JEP 210) will at least be a decent band aid for 8u40 (but 
even then, the problem of profile pollution when reusing a LambdaForm for two 
different indy callsites is not trivial and has to be solved. I’m not sure it 
has yet - I know Vladimir is working hard right now on this and is applying his 
excellent brain to the problem). However, I also don’t think that LambdaForm 
caching is enough for the long time solution.

We had some discussions how to implement indy call sites without LambdaForms 
after JVMLS in Santa Clara. Maybe John, Rickard or Vladimir can summarize some 
of the things we talked about, as I am just a code generation amateur in 
HotSpot and don’t want to embarrass myself in front of you guys. (Or I’ll post 
it later, when my head is clearer)

When it comes to putting resources on this, I can only say that I would love 
for this to happen and think it’s tremendously important for dynamic languages 
on the JVM.

Regards
Marcus

P.S. I agree with the tiered stuff too, but LambdaForms is the thing that 
really burns us in the warmup department right now. (and in the Metaspace 
department. Let’s not forget about that one).

P.P.S. Fredrik’s old post about how we did this in JRockit by inlining the indy 
callsites is worth a read again. The approach, is, however, probably also 
subject to some profiling pollution when you think about it. We never got far 
enough to really suffer from it, but one would expect it would crop up No extra 
byte code though. No extra classes. No extra metaspace.  
(https://blogs.oracle.com/ohrstrom/entry/pulling_a_machine_code_rabbit)… Maybe 
Fredrik himself can tell us something here? I


On 22 Aug 2014, at 22:08, Charles Oliver Nutter  wrote:

> Marcus coaxed me into making a post about our indy issues. Our indy
> issues mostly surround startup and warmup time, so I'm making this a
> general post about startup and warmup.
> 
> When I started working on JRuby 7 years ago, I hoped we'd have a good
> answer for poor startup time and long warmup times. Today, the answers
> are no better -- and in many cases much worse -- than when I started.
> 
> Here's a summary of our experience over the years...
> 
> * client versus server
> 
> Early on, we made JRuby's launcher use client mode by default. This
> was by far the best way to get good startup performance, but it led to
> us perpetuating the old question "which mode are you running in" when
> people reported poor steady-state performance.
> 
> * Tiered compiler
> 
> The promise of the tiered compiler was great: client-fast startup with
> server-fast steady state. In practice, tiered has failed to meet
> expectations for us. The situation is aggravated by the loss of
> -client and -server flags.
> 
> On the startup side, we have found that the tiered compiler never even
> comes close to the startup time of -client. For a nontrivial app
> startup, like a Rails app, we see a 50% reduction in startup time by
> forcing tier 1 (which is C1, the old -client mode) rather than letting
> the tiered compiler work normally.
> 
> Obviously limiting ourselves to tier 1 means performance is reduced,
> but these days our #1 user complain is startup time. So, we have AGAIN
> taken the step of putting startup-improving flags into our launch

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

[Marcus Lagergren]

To get into this faster it would be nice if the new private fields (or the 
existing ones for that matter) had a comment describing what they were for, e.g.

+ private final byte[] localTypes;
+ private final Class[] localClasses;

I can figure it out from the code, but it would have been a better starting 
point.

If that there are new apparent performance regressions caused by, e.g. profile 
pollusion from reusing existing method handles, I am fine with this. +1

/M

On 14 Mar 2014, at 14:17, Vladimir Ivanov  wrote:

> Paul,
> 
> You are looking at the other fix (8037210).
> The correct link is [1].
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] 
> http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html
> 
> On 3/14/14 4:38 PM, Paul Sandoz wrote:
>> 
>> On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov
>> mailto:vladimir.x.iva...@oracle.com>> wrote:
>> 
>>> FYI, this change isn't limited to only bytecode assembly improvements,
>>> but also contains caching of lambda forms for setters/getter of typed
>>> arrays.
>>> 
>> 
>> Do you mean for MethodHandles.arrayElementGetter/Setter? If so i don't
>> see relevant changes in:
>> 
>> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html
>> 
>> to say MethodHandleImpl.ArrayAccessor:
>> 
>> static final class ArrayAccessor {
>> /// Support for array element access
>> static final HashMap, MethodHandle> GETTER_CACHE = new
>> HashMap<>();  // TODO use it
>> static final HashMap, MethodHandle> SETTER_CACHE = new
>> HashMap<>();  // TODO use it
>> 
>> Paul.
>> 
>>> If there are any objections, I can back the caching logic out and
>>> include it into one of upcoming changes.
>>> 
>>> Best regards,
>>> Vladimir Ivanov
>>> 
>>> On 3/14/14 3:45 PM, Vladimir Ivanov wrote:
 http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/
 https://bugs.openjdk.java.net/browse/JDK-8037209
 440 lines changed: 313 ins; 67 del; 60 mod
 
 This is a cleanup of JSR292 code to improve bytecode assembly code for
 lambda forms.
 
 Contributed-by: john.r.r...@oracle.com
 
 Testing: jdk/java/{lang/invoke,util}, vm.mlvm.testlist, nashorn, jruby
 
 Configs: -ea -esa -Xverify:all -D...COMPILE_THRESHOLD={0,30}
 -D...PROFILE_LEVEL={0,1}
 
 Best regards,
 Vladimir Ivanov
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> 
>> 
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

[Marcus Lagergren]

Got catches, Paul!

/M

On 20 Feb 2014, at 18:57, Vladimir Ivanov  wrote:

> Paul,
> 
> Thanks for the feedback! See my answers inline.
> 
> Updated webrev:
> http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/
> 
> I finally figured out how to make caching work. This webrev contains these 
> changes.
> 
> I changed LF representation a bit and added 2 auxiliary method handles - 
> argument boxing and wrapping into Object[] and result unboxing. These 
> operations depend on actual type and can't be shared among arbitrary 
> combinators with the same basic type. They are used only during LF 
> interpretation and are completely ignored in compiled LFs.
> 
> On 2/20/14 7:51 PM, Paul Sandoz wrote:
>> Hi Vladimir,
>> 
>> I know just enough about this area to be dangerous
>> 
>> 
>> src/share/classes/java/lang/invoke/BoundMethodHandle.java
>> 
>>  865 private static final SpeciesData[] SPECIES_DATA_CACHE = new 
>> SpeciesData[4];
>> 
>> 
>> Only 3 elements are stored in the above array?
> Fixed.
> 
>> 
>> 
>> 
>> src/share/classes/java/lang/invoke/MethodHandleImpl.java
>> 
>>  634 // t_{i+2}:L=ValueConversions.unbox(t_{i+1}) OR 
>> ValueConversions.identity(t_{i+1})
>>  635 if (type.returnType().isPrimitive()) {
>>  636 names[UNBOX_RESULT] = new 
>> Name(ValueConversions.unbox(type.returnType()),
>>  637   names[TRY_CATCH]);
>>  638 } else {
>>  639 names[UNBOX_RESULT] = new Name(ValueConversions.identity(),
>>  640   names[TRY_CATCH]);
>>  641 }
>> 
>> 
>> You could create the form without the identity transform for the 
>> non-primitive case?
>> 
>>   final int UNBOX_RESULT = type.returnType().isPrimitive() ? nameCursor++ : 
>> 0;
>> ...
>> 
>>   if (UNBOX_RESULT > 0) { ...
>>   names[UNBOX_RESULT] = new 
>> Name(ValueConversions.unbox(type.returnType()), names[TRY_CATCH]);
>>   }
> I can, but it complicates matching and compiling the pattern in 
> InvokerBytecodeGenerator. I decided to keep the shape uniform for all cases.
> 
>> 
>> 
>>  699 try {
>>  700 GUARD_WITH_CATCH
>>  701 = IMPL_LOOKUP.findStatic(MethodHandleImpl.class, 
>> "guardWithCatch",
>>  702 MethodType.methodType(Object.class, 
>> MethodHandle.class, Class.class, MethodHandle.class, Object[].class));
>>  703 } catch (ReflectiveOperationException ex) {
>>  704 throw new RuntimeException(ex);
>>  705 }
>>  706 return GUARD_WITH_CATCH;
>> 
>> 
>> Should #704 be:
>> 
>>   throw newInternalError(ex);
>> 
>> ?
> Fixed. Also updated other places where RuntimeException was thrown.
> 
>> 
>> 
>> test/java/lang/invoke/MethodHandles/TestCatchException.java
>> 
>>  100 Object o = new Object();
>>  101 Object[] obj1 = new Object[] { "str" };
>>  102
>>  103 Object r1 = target.invokeExact(o, o, o, o, o, o, o, o, obj1);
>>  104 Object r2 = gwc.invokeExact(o, o, o, o, o, o, o, o, obj1);
>>  105 assertTrue(r1 != null);
>>  106 assertTrue(r1.equals(r2));
>> 
>> To be on the safe side should probably assert as follows:
>> 
>>   assertEquals(r1, obj);
>>   assertEquals(r2, obj);
> Fixed.
> 
> Best regards,
> Vladimir Ivanov
> 
>> Paul.
>> 
>> 
>> On Feb 19, 2014, at 10:46 PM, Vladimir Ivanov  
>> wrote:
>> 
>>> http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.00
>>> https://jbs.oracle.com/bugs/browse/JDK-8027827
>>> 354 lines changed: 193 ins; 91 del; 70 mod
>>> 
>>> OVERVIEW
>>> 
>>> MethodHandles.catchException combinator implementation is based on generic 
>>> invokers (MethodHandleImpl$GuardWithCatch.invoke_*). It is significantly 
>>> slower than a Java equivalent (try-catch).
>>> 
>>> Future Nashorn performance improvements require catchException combinator 
>>> speed to be on par with try-catch in Java.
>>> 
>>> So, it should be represented in a more efficient form.
>>> 
>>> I chose the following lambda form representation:
>>> 
>>>  t_{i}:L=ValueConversions.array(a1:L,...,a_{k}:L);
>>> t_{i+1}:L=MethodHandleImpl.guardWithCatch(t_{p1}, t_{p2}, t_{p3}, t_{i}:L);
>>> t_{i+2}:I=ValueConversions.unbox(t7:L);
>>> OR :L=ValueConversions.identity(t_{n+1})
>>> OR :V=ValueConversions.ignore(t_{n+1})
>>> 
>>> where:
>>>  a1, ..., a_{k} - arguments
>>>  t_{p1}, t_{p2}, t_{p3} - target method handle, exception class, catcher 
>>> method handle respectively; passed as bounded parameters;
>>> 
>>> During lambda form compilation it is converted into bytecode equivalent of 
>>> the following Java code:
>>>  try {
>>>  return target.invokeBasic(...);
>>>  } catch(Throwable e) {
>>>  if (!exClass.isInstance(e)) throw e;
>>>  return catcher.invokeBasic(e, ...);
>>>  }
>>> 
>>> There's a set of microbenchmarks (attached to the bug) I wrote to verify 
>>> performance characteristics of new implementation.
>>> 
>>> FURTHER WORK
>>> 
>>> What is m

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

[Marcus Lagergren]

This looks good, and we have done a significant number of test runs to verify 
its integrity.

I say ship it. +1

We know that there are some issues with sun.misc.ValueConversion.castReference 
and similar internal methods not being inlined, but as far as I can understand 
this is a separate issue that will be addressed. By rewriting a guard for 
Nashorn to not use castReference in the fast case, I get record indy 
performance with your catch combinator.

/M (jdk9 reviewer)

On 19 Feb 2014, at 22:46, Vladimir Ivanov  wrote:

> http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.00
> https://jbs.oracle.com/bugs/browse/JDK-8027827
> 354 lines changed: 193 ins; 91 del; 70 mod
> 
> OVERVIEW
> 
> MethodHandles.catchException combinator implementation is based on generic 
> invokers (MethodHandleImpl$GuardWithCatch.invoke_*). It is significantly 
> slower than a Java equivalent (try-catch).
> 
> Future Nashorn performance improvements require catchException combinator 
> speed to be on par with try-catch in Java.
> 
> So, it should be represented in a more efficient form.
> 
> I chose the following lambda form representation:
> 
>  t_{i}:L=ValueConversions.array(a1:L,...,a_{k}:L);
> t_{i+1}:L=MethodHandleImpl.guardWithCatch(t_{p1}, t_{p2}, t_{p3}, t_{i}:L);
> t_{i+2}:I=ValueConversions.unbox(t7:L);
> OR :L=ValueConversions.identity(t_{n+1})
> OR :V=ValueConversions.ignore(t_{n+1})
> 
> where:
>  a1, ..., a_{k} - arguments
>  t_{p1}, t_{p2}, t_{p3} - target method handle, exception class, catcher 
> method handle respectively; passed as bounded parameters;
> 
> During lambda form compilation it is converted into bytecode equivalent of 
> the following Java code:
>  try {
>  return target.invokeBasic(...);
>  } catch(Throwable e) {
>  if (!exClass.isInstance(e)) throw e;
>  return catcher.invokeBasic(e, ...);
>  }
> 
> There's a set of microbenchmarks (attached to the bug) I wrote to verify 
> performance characteristics of new implementation.
> 
> FURTHER WORK
> 
> What is missing is lambda form caching. The plan is to have a single lambda 
> form per basic type, but it needs more work - current representation is 
> suitable for sharing on bytecode level, but lambda form interpretation 
> doesn't work well (arguments boxing + result unboxing are problematic).
> 
> TESTING
> 
> Tests: microbenchmarks, jdk/java/lang/invoke/, nashorn with optimistic types 
> (unit tests, octane).
> 
> Tested in 2 modes:
>  * COMPILE_THRESHOLD=30
>  * COMPILE_THRESHOLD=0 -Xverify:all
> 
> OTHER
> 
> 1) Update of cached name and member in LF compilation loop (see 
> InvokerBytecodeGenerator.generateCustomizedCodeBytes) fixes a bug during 
> compilation of selectAlternative when running with COMPILE_THRESHOLD=0.
> 
> 2) As part of this change, I fix existing bug [1], so I add regression test 
> for it.
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8034120

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: RFR (XS): 8027823: catchException combinator fails with 9 argument target

[Marcus Lagergren]

Wohoo! Let us know when you have something we can test drive. I have some JFR 
recordings that show that the catch combinator indeed takes time in otherwise 
well behaved benchmarks (even though the catch is never entered)

/M

On 12 Nov 2013, at 17:14, John Rose  wrote:

> On Nov 12, 2013, at 1:00 AM, Attila Szegedi  wrote:
> 
>> Just saw this - thank you for the fix!
> 
> I pushed Vladimir Ivanov's fix.  Now we are thinking about unboxed paths for 
> try/catch, since you guys use them for deopt.
> 
> — John
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: JVM Summit Wrokshop/talk request

[Marcus Lagergren]

+1 to that.  We could probably host something in Stockholm too, if there is 
interest. (We are the third largest Oracle JVM engineering site in the world 
after Santa Clara and Burlington, MA).

/M

On Apr 11, 2013, at 10:09 PM, Charles Oliver Nutter  wrote:

> I would absolutely love to have a European edition of the JVM Language
> Summit. It's not a very complicated event to put together, and it
> would give us an opportunity to meet with more language folks than can
> make it to California for JVMLS.
> 
> You could count on my attendance.
> 
> - Charlie
> 
> On Thu, Apr 11, 2013 at 5:30 AM, MacGregor, Duncan (GE Energy
> Management)  wrote:
>> I would certainly be interested, though travel budgets do seem to be tight
>> this year.
>> 
>> We could probably host it here in Cambridge if you guys want to come over
>> to the UK.
>> 
>> On 09/04/2013 08:19, "Julien Ponge"  wrote:
>> 
>>> Just an idea: would some of you be interested in having a meeting at some
>>> point in Europe?
>>> 
>>> I (or Rémi) can probably organise something at our Unis.
>>> 
>>> - Julien
>>> 
>>> On Apr 9, 2013, at 4:55 AM, Mark Roos  wrote:
>>> 
 Thanks for the interest.
 
 I added this workshop to my proposal.  Inputs are welcome on how to
 make it a good workshop.
 
 mark
 
 Improving the performance of InvokeDynamic
 
 Now that we have some experience with InvokeDynamic its time
 to discuss strategies and efforts for performance improvement.
 We expect to have experts, HotSpot implementers and users
 discussing how to get the best performance
 possible.___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> 
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: JVM Summit Wrokshop/talk request

[Marcus Lagergren]

Hopefully, I'll be there. After 18 months of Nashorn on the JVM, I think I'm 
starting to know what I'm talking about, but who knows… 

/M 

On Apr 9, 2013, at 11:47 AM, Jeroen Frijters  wrote:

> I will be there representing the JVMs with a "suboptimal" implementation ;-)
> 
>> -Original Message-
>> From: mlvm-dev-boun...@openjdk.java.net [mailto:mlvm-dev-
>> boun...@openjdk.java.net] On Behalf Of Jim Laskey
>> Sent: Monday, April 8, 2013 23:02
>> To: Da Vinci Machine Project
>> Subject: Re: JVM Summit Wrokshop/talk request
>> 
>> John Rose and Christian Thalinger will likely there from the JVM team.
>> Marcus Lagergren and Attila Szegedi from the Nashorn team are not
>> confirmed but if available would be good for user experience.
>> 
>> Cheers,
>> 
>> -- Jim
>> 
>> 
>> On 2013-04-08, at 5:39 PM, Mark Roos > <mailto:mr...@roos.com> > wrote:
>> 
>> 
>>  Ok Charles is one expert,  how about some folks doing the jvm
>> implementation?
>> 
>>  Any thoughts on who that could be
>> 
>>  regards
>>  mark___
>>  mlvm-dev mailing list
>>  mlvm-dev@openjdk.java.net <mailto:mlvm-dev@openjdk.java.net>
>>  http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> 
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Perf regression since b72

[Marcus Lagergren]

At least for us, the InlineSmallCode workaround pretty much compensated 
entirely for the loss of tiered. This may not be the case for you, but I hope 
so. Benchmarking with tiered is very "noisy" with lots of standard deviation.

/M

On Apr 1, 2013, at 9:23 PM, Christian Thalinger 
 wrote:

> 
> On Mar 30, 2013, at 1:56 AM, Charles Oliver Nutter  
> wrote:
> 
>> I've been fiddling about with performance a bit again recently, and have 
>> noticed a perf degradation since b72. I mentioned this to the Nashorn guys 
>> and Marcus discovered that InlineSmallCode=2000 helped them get back to b72 
>> performance. I can confirm this on JRuby as well, but in any case it seems 
>> that something has regressed.
>> 
>> Here's some numbers with JRuby. Numbers are for b72, hotspot-comp, and 
>> hotspot-comp with InlineSmallCode=2000. You can see that current 
>> hotspot-comp builds do not perform as well as b72 unless that flag is passed.
>> 
>> https://gist.github.com/headius/de7f99b52847c2436ee4
>> 
>> I have not yet started to explore the inlining or assembly output, but I 
>> wanted to confirm that others are seeing this degradation.
>> 
>> My build of hotspot-comp is current.
>> 
>> I do have some benchmarks that look fine without the additional flag 
>> (neural_net, for example), so I'm confused what's different in the degraded 
>> cases.
> 
> I'm not sure if Marcus talked to you already about this but there are two 
> fixes that caused this regression:
> 
> 1.  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007439
> 
> which was fixed by:
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010222
> 
> in HS25-b24.
> 
> 2.  We turned off tiered compilation:
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005811
> 
> The InlineSmallCode=2000 is a way to work around the tiered slowdown.
> 
> -- Chris
> 
>> 
>> - Charlie
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Google Dart

[Marcus Lagergren]

FYI,

Google Dart now has a twitter account : https://twitter.com/#!/dart_lang and 
Website is up http://www.dartlang.org/

/M

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev