7 ms·

Java languages issues: classfile format, continuation, immutability, TCO

21 points by gtani 15y ago

kevingadd 15y ago
The presenter seems like he might not be living in the real world. 128-bit floating point? Why exactly? What hardware out there supports this, what problems does it solve that 64-bit floats or bignums don't? Why add more intrinsic types to the type system that will need vm and library changes when you could implement them in java? Suggesting that fields and properties be the same thing suggests a lack of understanding as to why they are different. Traits, classes and interfaces, likewise, are not the same thing, and suggesting they are makes me wonder if the author knows what problems each feature is used to solve. Only someone who doesn't know how hard date and time classes are to design would rattle off 'a better date and time' with no suggestion of what better looks like and how you achieve it. Access to all variables at runtime? Sure, as long as you don't mind disabling dozens of important optimizations for a feature only debuggers have good reason to use. Bundle an assembler with the jvm? For what purpose? Java apps are already far less portable than they should be. his comments on the class file format also suggest confusion: nesting types inside method definitions only makes sense in an environment like python where type definitions can be created dynamically at any time. Java simply doesn't work that way, so his proposed nesting would complicate class loading for no benefit. The 64k limit is ugly, but any method with 64k worth of code in it suggests deep architectural problems that will complicate everything - compilation, jitting, debugging, static analysis. I never thought I'd be longing for sun's inept stewardship of java, but If this is what oracle has to offer...
- blinkingled 15y ago
  Well, I suppose you skipped over the "Disclaimer" slide :)
- ac-slater 15y ago
  > 128-bit floating point? Why exactly? What hardware out there supports this, what problems does it solve that 64-bit floats or bignums don't? Why add more intrinsic types to the type system that will need vm and library changes when you could implement them in java? Not to mention his example of inaccurate floating point was "2.0 + 2.0 = 3.999999999999999979" When 2.0 and 4.0 are exactly representable in both IEEE 754 float and double.
- RodgerTheGreat 15y ago
  I agree. The general thrust of things seemed to be "We should redesign the JVM and along the way totally change the Java language so that it's more like Python. Because."
zohebv 15y ago
Weird presentation. He has a disclaimer upfront that he doesn't really know much about the JVM. He wants a Decimal class? Fine go ahead and write one. You can easily emulate it using an int with a globally accepted denominator value, but whatever. He wants the class file format to be changed from stack machine to register machines. And exactly why? He wants deadlock detection on every lock acquisition? So lock acquisition is now O(n) instead of O(1). Fine, go ahead and write your own expensive deadlock detecting lock class. Why does he need the "JVM" to support this? Also what does - synchronized must die because we have > 2 CPUs- mean. One would think this makes synchronization more important. He is not even proposing an actor model as an alternative. What does non threadsafe objects not being allowed to escape mean? Escape into a different thread? How does he propose to do the analysis required to identify such objects? Statically/Runtime? Is this even tractable? What level of granularity does he expect the lock on an "escaped" object to be, if the object itself is a graph of of many objects? I like how he pretends to solve all GC problems in one slide, using "escape" analysis or whatever. Everything will be concurrent and nobody will pause. And there seems to be some persistent obsession with the Date and Time classes. He has also somehow managed to combine immutability with autoboxing.
- psykotic 15y ago
  > So lock acquisition is now O(n) instead of O(1). You can do incremental deadlock detection in O(1) time per waiter assuming you are okay with treating hash table operations as O(1), so that successful lock acquisition takes O(w) time where w is the number of threads directly or indirectly waiting on the lock-acquiring thread. A really simple example would be Herlihy's dreadlocks: http://www.unine.ch/transact08/slides/Herlihy-Dreadlocks.pdf http://www.unine.ch/transact08/slides/Herlihy-Dreadlocks.pdf. He does lossy deadlock detection using Bloom filters and bit vectors, so it's truly constant time per waiter at the cost of false negatives. But the same idea works for exact deadlock detection if you use concurrent hash tables. The only question is whether you'd want to do that in practice. The overhead of using this as the default mode of operation would absolutely be prohibitive. But all that is just an aside for your edification, because frankly I don't see anything in the slides that requires instant deadlock detection. He's just asking for a standardized DeadlockError exception that will be thrown to waiting threads involved in a cycle so as to break the deadlock. Most practical deadlock detectors run periodically and that's consistent with what he's requesting. > And there seems to be some persistent obsession with the Date and Time classes. Why not? Java's Date/Time classes have a broken design. That's why everyone uses Joda-Time.

21 points by gtani 15y ago

The presenter seems like he might not be living in the real world. 128-bit floating point? Why exactly? What hardware out there supports this, what problems does it solve that 64-bit floats or bignums don't? Why add more intrinsic types to the type system that will need vm and library changes when you could implement them in java? Suggesting that fields and properties be the same thing suggests a lack of understanding as to why they are different. Traits, classes and interfaces, likewise, are not the same thing, and suggesting they are makes me wonder if the author knows what problems each feature is used to solve. Only someone who doesn't know how hard date and time classes are to design would rattle off 'a better date and time' with no suggestion of what better looks like and how you achieve it. Access to all variables at runtime? Sure, as long as you don't mind disabling dozens of important optimizations for a feature only debuggers have good reason to use. Bundle an assembler with the jvm? For what purpose? Java apps are already far less portable than they should be. his comments on the class file format also suggest confusion: nesting types inside method definitions only makes sense in an environment like python where type definitions can be created dynamically at any time. Java simply doesn't work that way, so his proposed nesting would complicate class loading for no benefit. The 64k limit is ugly, but any method with 64k worth of code in it suggests deep architectural problems that will complicate everything - compilation, jitting, debugging, static analysis. I never thought I'd be longing for sun's inept stewardship of java, but If this is what oracle has to offer...

blinkingled 15y ago
Well, I suppose you skipped over the "Disclaimer" slide :)
ac-slater 15y ago
> 128-bit floating point? Why exactly? What hardware out there supports this, what problems does it solve that 64-bit floats or bignums don't? Why add more intrinsic types to the type system that will need vm and library changes when you could implement them in java? Not to mention his example of inaccurate floating point was "2.0 + 2.0 = 3.999999999999999979" When 2.0 and 4.0 are exactly representable in both IEEE 754 float and double.
RodgerTheGreat 15y ago
I agree. The general thrust of things seemed to be "We should redesign the JVM and along the way totally change the Java language so that it's more like Python. Because."

zohebv 15y ago

Weird presentation. He has a disclaimer upfront that he doesn't really know much about the JVM. He wants a Decimal class? Fine go ahead and write one. You can easily emulate it using an int with a globally accepted denominator value, but whatever. He wants the class file format to be changed from stack machine to register machines. And exactly why? He wants deadlock detection on every lock acquisition? So lock acquisition is now O(n) instead of O(1). Fine, go ahead and write your own expensive deadlock detecting lock class. Why does he need the "JVM" to support this? Also what does - synchronized must die because we have > 2 CPUs- mean. One would think this makes synchronization more important. He is not even proposing an actor model as an alternative. What does non threadsafe objects not being allowed to escape mean? Escape into a different thread? How does he propose to do the analysis required to identify such objects? Statically/Runtime? Is this even tractable? What level of granularity does he expect the lock on an "escaped" object to be, if the object itself is a graph of of many objects? I like how he pretends to solve all GC problems in one slide, using "escape" analysis or whatever. Everything will be concurrent and nobody will pause. And there seems to be some persistent obsession with the Date and Time classes. He has also somehow managed to combine immutability with autoboxing.

psykotic 15y ago
> So lock acquisition is now O(n) instead of O(1). You can do incremental deadlock detection in O(1) time per waiter assuming you are okay with treating hash table operations as O(1), so that successful lock acquisition takes O(w) time where w is the number of threads directly or indirectly waiting on the lock-acquiring thread. A really simple example would be Herlihy's dreadlocks: http://www.unine.ch/transact08/slides/Herlihy-Dreadlocks.pdf http://www.unine.ch/transact08/slides/Herlihy-Dreadlocks.pdf. He does lossy deadlock detection using Bloom filters and bit vectors, so it's truly constant time per waiter at the cost of false negatives. But the same idea works for exact deadlock detection if you use concurrent hash tables. The only question is whether you'd want to do that in practice. The overhead of using this as the default mode of operation would absolutely be prohibitive. But all that is just an aside for your edification, because frankly I don't see anything in the slides that requires instant deadlock detection. He's just asking for a standardized DeadlockError exception that will be thrown to waiting threads involved in a cycle so as to break the deadlock. Most practical deadlock detectors run periodically and that's consistent with what he's requesting. > And there seems to be some persistent obsession with the Date and Time classes. Why not? Java's Date/Time classes have a broken design. That's why everyone uses Joda-Time.