infrastructure update: wiki location, etc.

[John Rose]

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