infrastructure update: wiki location, etc.

[LaMothe, Ryan R]

Thanks again John.

I can respect your opinions. The main point I was trying to highlight is that over the past 15 years most (all?) of the JLS and JVM has been dictated by individuals in an "ivory tower" down to the masses, even when the masses were complaining ad. nauseum on bug tickets that were getting closed without comment by Sun. There are many obvious items that do need to be addressed during Sumatra development, specifically because many of the decisions that may be wrong 99.99% of the time to some are the exact reasons Java is basically non-existent in high performance and scientific communities (e.g. non-contiguous multi-dimensional arrays, lack of unsigned types, etc.). Moving compute to GPUs is going to, at least initially, be most valuable to these exact people. So obvious doesn't mean wrong, but if we choose to ignore the obvious, we should at least take into account the reasons why millions of people choose not to use Java due to a lack of those exact features.

__________________________________________________

Ryan LaMothe


-----Original Message-----
From: John Rose [mailto:john.r.rose at oracle.com] 
Sent: Monday, October 29, 2012 12:17 PM
To: LaMothe, Ryan R
Cc: Frost, Gary; sumatra-dev at openjdk.java.net
Subject: Re: infrastructure update: wiki location, etc.

On Oct 29, 2012, at 11:49 AM, LaMothe, Ryan R wrote:

> The reason I asked is because I believe the two are intimately tied...no matter how much we can do in native Java to execute code on GPUs, there are a number of glaringly obvious things (at least to most people) in the language and JVM that simply need to be fixed at some point.

I expect Sumatra to lead to a few well-chosen JVM changes.

But I have to say that discomfort does not equal insight, and glaringly obvious is not the same as lucidly clear.  Cue the story about the blind men and the elephant...

Especially in the area of Java language design (but also with JVM design), although people can agree about the existence of pain points, the first suggested fix, especially if passionately urged as obvious even to a dunce, is wrong 99.99% of the time.  The reason is simple:  We are trying to optimize a complex artifact (JLS, JVM) used by many people (millions) in divergent, mutually inconsistent ways.

If the problem is important, the hundredth suggested fix is usually wrong, too.

Here's specific example.  The way I see it, the 15-year-old JVM data model doesn't quite fit to GPU data types (e.g., vector values, complex numbers, fortran arrays).  Java folks have been worrying about this problem for 15 years, which means that no "obvious" solution will be correct.  ("Obviously we need a primitive type for complex numbers."  "Obviously we need operator overloading." "Obviously we need a new array syntax for rectangular arrays."  - All wrong, in part because they are narrowly-conceived language changes.)  Happily, I think there may be a correct-enough-though subtle-solution.  See my value-types blog entry for some thinking, and a forthcoming JEP for a more concrete proposal.

- John