Future of the JVM presentation from PhillyETE

[jamie...@typesafe.com]

Cliff Click, Charlie Hunt, Doug Lea and Michael Pilquist answer questions about where the JVM is and where it's going.  Great anecdotes.  See the panel here.

Doug also has some fun trolling those who pin to cores.  :)

[Simone Bordet]

Hi,

I'm surprised no one asked for a non-stop-the-world GC (even in young
gen) in the "what would you see in the JVM".

Given the said trend towards 1024 cores, and I guess bigger, bigger
memory (heck my Nexus4 has 2 GiB, I remember when that figure was only
available in super-expensive servers), isn't the JVM as it stands
severely limited in scaling ?

I guess that falls in the political issues Doug Lea was talking about :|

I also wonder why - perhaps naively, given that Azul proved it
possible - there currently seems to be no efforts by big names in
implementing a C4 clone... perhaps patents make the manoeuvre space
really limited ?

Surprised to hear that STM is dead.

Thanks for sharing the link.

--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

[Michael Barker]

> Cliff Click, Charlie Hunt, Doug Lea and Michael Pilquist answer questions
> about where the JVM is and where it's going. Great anecdotes. See the
> panel here.

Cheers, for the link. BTW, nice work on the chairing the panel. Good
set of questions that elicited some broad responses. Seen a few
panels recently that were appalling due to a bad chair.

Mike.

[Kirk Pepperdine]

On 2013-05-06, at 11:13 PM, Simone Bordet <simone...@gmail.com> wrote:

> Hi,
>
> On Mon, May 6, 2013 at 4:46 PM, <jamie...@typesafe.com> wrote:
>> Cliff Click, Charlie Hunt, Doug Lea and Michael Pilquist answer questions
>> about where the JVM is and where it's going. Great anecdotes. See the
>> panel here.
>>
>> Doug also has some fun trolling those who pin to cores. :)
>
> I'm surprised no one asked for a non-stop-the-world GC (even in young
> gen) in the "what would you see in the JVM".
>
> Given the said trend towards 1024 cores, and I guess bigger, bigger
> memory (heck my Nexus4 has 2 GiB, I remember when that figure was only
> available in super-expensive servers), isn't the JVM as it stands
> severely limited in scaling ?

Indeed, what I'm finding is that GC frequency is putting just enough pressure on the schedulers in some cases to diagnose the system as lock bound (ok, safe pointing does't use locks but....).

I'd like to see a GC that runs continuously using un-used cores.


-- Kirk

[Martin Thompson]

Thanks Jamie and I'd like to echo Mike's comments that it is nice to see a well chaired panel :-)

The general discussion was excellent and I'd like to highlight a few points in the presentation.

1. Totally agree on the Simone's point that GC was not covered.  Not only should GC be concurrent we need as much as possible to be concurrent in the JVM and time to safepoints beaten down as Gil Tene often points out.
2. I found a big conflict in the panel on one side supporting the need for a single shared-memory with coherent cache access then to talk about distributed systems.  Why not have one programming model that works for both distributed and local?  I tend to think that all execution contexts are remote and we message pass to share state.  Transputers, Actors, and the CSP mantra can be far more performant and easier to reason about than many threads racing to update the same contended data.
3. The discussion of structs and memory locality was important to have but I felt the responses were a bit anemic.  This is a hugely important topic and deserves a much more detailed discussion.  I do agree that better intrinsics are the way to go rather than get involved in the politics of language changes.  Good intrinsics sidestep the whole issue and get everyone benefiting sooner without any backwards compatibility issues.  To do this really well, it is critical we carry type information through for collections rather than erase it via the current generics approach.

[Michael Barker]

> I found a big conflict in the panel on one side supporting the need for a
> single shared-memory with coherent cache access then to talk about
> distributed systems. Why not have one programming model that works for both
> distributed and local? I tend to think that all execution contexts are
> remote and we message pass to share state. Transputers, Actors, and the CSP
> mantra can be far more performant and easier to reason about than many
> threads racing to update the same contended data.

I found that discussion interesting too. Especially after watching
Herb Sutter's marathon 2.5 hour talk[1][2] on the C++ memory model, he
pointed to a research paper[0] that suggests that coherent caches are
unlikely to disappear and will continue to scale out to reasonably
high core counts.

[0] http://research.cs.wisc.edu/multifacet/papers/tr2011-1_coherence_stays.pdf
[1] http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2
[2] http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-2-of-2

[Martin Thompson]

These talks from Herb are excellent and give great background.  However I cannot understand the common desire to continue encouraging people to work on contended access to shared data and the concurrency and performance issues that result.  Every project I've seen where even good people have tried to make concurrent access to a complex business model are littered with concurrency bugs and contention issues.  

The Go, Akka, and Erlang folk seem to be only vaguely mainstream folk doing something different other than pretty much everyone in the HFT space who are taking a pseudo Actor approach.  Fork-Join addresses parallelism but not concurrency and is a bitch to debug.  STM is a mess on anything remotely complex from a domain model perspective.  Then there is using locks to manage updates to a domain model, now that has me running away in sheer terror.  The vast majority of programmers just resort to using an RDBMS to manage the concurrency for them and this greatly restricts modelling and scalability.

[jamie...@typesafe.com]

Thanks for the kudos on leading the panel.  It was a lot of fun. GC was definitely something worth discussing.  One thing I wish I'd done was moderate more effectively to leave more time for audience questions.  Tough when you're enjoying the discourse so much.

I'll just have to do another one next year.  Charlie says he'd like to come back, and I could probably sway Doug.  Alexy Shipilev would be interested, I think.  Anyone else?  :)

[Kirk Pepperdine]

I think I'd like to watch it live.. be hard to keep quiet though ;-)

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Sand Stone]

+1 for the panel discussion especially the struct part. 

One comment: it seems strange no question on SIMD instruction support. With AVX, and especially the up and coming 256 bit integer instructions in Haswell, the wide instructions are actually more important, in my opinion, than threads, and even GC. 

The SIMD instructions seem to be the high candidates to be exposed as JVM intrinsics. 

[Martin Thompson]

A discussion of SIMD would be interesting.  Even Dart is getting this support!

https://docs.google.com/presentation/d/1zfucLA3XNqRb7W56ldU_Biya-IrS00QmSuXNYwewlyg/edit#slide=id.p19

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Frank Hsueh]

and Mono (open source MS CLI impl) has had it for a whiles now

http://docs.go-mono.com/index.aspx?link=N:Mono.Simd

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Frank Hsueh | frank...@gmail.com