Whither JDK 7?

[Arved Sandstrom]

On Fri, 04 Jun 2010 14:16:27 -0700, Nebulous wrote:

[ SNIP ]

Ah, the more things change, the more they stay the same.

[ SNIP ]

Yeah, that turn of phrase I remember. As a constant mantra it's somewhat
creepy...I'd hate to work with the guy because I'd always be wondering
when he's going to completely unwrap.

AHS

 

[Arne Vajhøj]

Even better, continue working with JDK 6, and if you're a
dyed-in-the-wool JVM person, expand your programming horizons with Scala
or Clojure.

(defn drop-bombshell []
(.println System/out "I already know Clojure, actually."))

Yeah, I was a scout once, and still stick to that whole "be prepared"
thing.

Clojure comes in handy when you don't need seriously blazing speed and
the problem lends itself to a functional style.

Scala is more Java like.

Actually what Java really needs for speed these days is an API that lets
you do arbitrary SIMD math on the machine's GPU. That seems to be where
all the really sneaky optimizations are in rendering/number crunching
these days, ones that JIT won't get you, and pretty much everything else
you want to do is I/O bound.

For true number crunching: yes.

But true number crunching is not a primary area for Java.

Actually, the other thing we really need is OS/JVM integration so the JVM
heap plays nicer with paging and multitasking.

I believe that both work fine with current JVM's.

I foresee a day when
there's a small kernel written in C that bootstraps and provides the main
API services for a JVM or similar VM, and all user-mode applications run
in the VM. If the VM is stable enough, they can't crash it, just catch
unhandled exceptions. The JVM's security features make it almost ideal
for something like this, combined with its maturity and JIT.

Microsoft did something similar with C# in this research project:
http://research.microsoft.com/en-us/projects/singularity/

Arne

 

[Arne Vajhøj]

He was an SOB. It was a great day for the Philippines when Corazon
Aquino replaced him. I didn't know he was a LISP programmer too.

Marcos??

Arne

 

[Arne Vajhøj]

Well, speak of the [insult deleted] and look who appears.

No, you're the devil.

None of the nasty things that you have said or implied about me are at
all true.

Nobody missed you around here, so ...

Arne

 

[Arne Vajhøj]

JDK 7, among other things, is supposed to provide features that should
benefit functional and dynamic languages, so Scala and Clojure could
theoretically take advantage of JDK 7, too.

With the JDK open sourced, nothing stops you from downloading it and
trying the new features, and complain with the committee who's
designing them

Even before being open sourced SUN put out beta versions of the binaries
for people to try.

Arne

 

[ClassCastException]

I believe that both work fine with current JVM's.

If everything you're doing (except the OS) is in the JVM, it works fine.
If what's in the JVM is quite small, it works fine. But if the JVM heap
grows to say a gig or two and you have Firefox, Photoshop, and a dozen
other big applications open as well, the JVM has a tendency to get
swapped out, and when it's used again and a major collection is
triggered, ouch. Nonresponsive for literally *minutes*.

The G1 collector that's supposed to be in JDK7 (thus bringing this topic
full-circle) might alleviate that somewhat, given what I understand about
how it will work. But the optimum logically must be if the paging and the
garbage collector cooperated in some way, which pretty much requires at
the very least adding some kind of specific API support for garbage
collection to the OS.

Ultimately, though, there are security, stability, portability, and other
benefits to standardizing on a VM as user-mode application host and then
performance benefits to moving that VM into the OS and much OS
functionality (however much is not kernel-mode) into the VM and API
library.

 

[Tom Anderson]

If everything you're doing (except the OS) is in the JVM, it works fine.
If what's in the JVM is quite small, it works fine. But if the JVM heap
grows to say a gig or two and you have Firefox, Photoshop, and a dozen
other big applications open as well, the JVM has a tendency to get
swapped out, and when it's used again and a major collection is
triggered, ouch. Nonresponsive for literally *minutes*.

On which subject, has anyone pointed to this:

http://www.managedruntime.org/
http://www.networkworld.com/news/2010/061510-azul-systems-searches-for-managed.html?hpg1=bn

yet?

Azul, who are pretty expert and large-scale java performance, have this
idea to make the JVM and OS work a bit more closely together, by adding
kernel modules to the OS (so far, just linux) and then modifying the JVM
to use them. I don't know about the details, as information is thin on the
ground, but it's interesting stuff.

Might even be something interesting for Patricia to work on.

tom