TSSJS Trip Report

I’m off to another conference – this time TSSJS in Las Vegas.  Continuing my trend of having bad flying experiences, my flight out was delayed an hour for mechanical failure, complete with gate change.  Other than that and an amazingly choppy landing, getting to Vegas was easy.  I found time to walk the strip, take in the sights & sounds, eat too much, and do some dancing.  I even managed to take in a show – Cirque de Soleil’s KA.  The show is part acrobatics, part story-telling via dance, part circus, part musical, all extravaganza and a totally awesome stage set.  The stage features a basketball court sized chunk of stage which can go up or down a 100ft or more, rotate, be stood on vertically edge, or flipped end over end.  KA uses it in every possible configuration, including some incredible ninja fight/dance scenes where the stage is slowly lifting and turning and becoming more vertical as the fight turns into a cliff-hanging scramble/chase and the “villains” are falling off to their doom as the “hero” is clinging by a thread.

True to form, the return trip featured a major Bay Area thunderstorm which delayed all flights (mine included) into all three major bay area airports for at least 2 hours, plus plenty of chop getting out of LA and over the Sierras.  But I’m back safe and sound once again.

TSSJS looked like it was doing well this year; the main speaking hall/room was packed for the keynote sessions, there was a lot of buzz going around.  I caught up with a bunch of old friends and reconnected with some new ones from FOSDEM.  I especially enjoyed Kirk Pepperdine’s Java performance analysis talk where he covers a basic decision tree to tease apart I/O issues from GC issues from CPU issues from other causes.

I myself sat on a panel: Who Invited These Other Languages to my JVM? We managed to talk for entire hour and had plenty more to say.  My stance in a nutshell: Java appears to have plateaued (although Projects Lambda and Coin may give it a serious boost), but that the JVM is on a roll.  Where people used to target C  as their “assembly” of choice years ago (to avoid having to do code-generation), they now target the JVM – which avoids the code-gen AND supplies a GC, AND a well-understood threading model, plus true type-safety.

I presented “A JVM Does That?”, a low-level romp through a JVM’s innards discussing all the services provided by a JVM, and why they exist – and perhaps why they should NOT exist, or should exist elsewhere, or should not ever ever have been part of the spec.


10 thoughts on “TSSJS Trip Report

  1. I was sorry to miss your talk, but it was scheduled opposite another talk I couldn’t live without by just a little bit more. The slides look like it was an informative hour.

    Hope to learn more through your blog!



  2. Nice slide deck about unintended consequences of incremental addition of nice ideas. A few comments:

    There are real uses for weak references as a workaround for Java’s lack of a feature to add fields to a class at runtime. So I don’t think you should get rid of weak references unless you can add that feature (probably easy except for security and all the other practicalities). But I agree that caches would be better managed by the application; the application needs a better way to be informed by the GC whether memory is scarce or abundant so it can adjust cache sizes.

    MappedByteBuffer is an even more egregious example of the brokenness of using finalizers to release resources; in this case virtual address space, which is not really an OS resource.

    I don’t buy your idea that 64 bits is enough. They said that about 32 bits, and probably about 16, and maybe even about 12! In my opinion, which I know no one agrees with, the only reason Java has primitive types such as int separate from real types such as (Big)Integer is a combination of lack of courage (it would have taken a very large amount of courage at the time) and lack of foresight of how much JIT compilers would be able to do (I doubt anyone anticipated that). An infinite-range integer that turns out not to use the whole range is a lot like a biased lock! Certainly the fast case could be JITed to be fast. You will blanch at this, but I would claim that the JIT could “easily” do range inference to identify most code where the slow case cannot occur at all and eliminate all runtime checks.

    • Hi Dave, in around 13years using java for quite various tasks I don’t remember a single time I needed an infinite precision integer. Perhaps, I have used unsigned 128bit twice and that would sum all cases beyond 64bit. I am perfectly sure you know better how much profiling and inlining it’d take to optimize the infinite integer beyond the 64bit. On top of that they cannot be passed by value b/c they size is undefined by default. I believe that also would make them quite incompatible with the stack based layout. Imagining sizeof + data to be passed in the stack looks quite weird to me and it’s definitely not compatible with the maxStack/locals sizes.

      Actually I’d see use JIT to naturally support vector operations via the SSE registers and that will not even require changing of the spec and relatively easy to recognize patterns (plus proper alignment).

      • Sun has been adding automatic SSE support to the server compiler, and Azul Systems’ has integrated that work… but I believe it to be incomplete still.


  3. @bestsss Integers are immutable. The consequences I will leave as a thought exercise.

    I am sure you are correct that not everyone needs integers larger than a certain size. The upper bound on size needed varies among projects, though. I was not suggesting that the JIT could make integers of all sizes become super fast, only that it could eliminate imposing a performance penalty for the existence of large integers on methods that don’t use them.

  4. Thanks, cliff! That’s good news if the SSE support is in later stage.

    @Dave, I guess I have misunderstood your point (sure, I know the immutable classes). Based on the initial Java design remark, I thought you’d like to have something like “infinite_int” that’s a value type, allocated on the stack and copied each time (much like struct in C#, except growable). It looks you merely want a JIT optimized BigInteger that behaves just like a normal int for “smaller” values and it has the standard operators (+, -, etc) applicable. With 64bit architecture I guess there are enough bits to keep a pointer + int value and inflate, if need be, after the escape analysis. Thanks for the clarification.

  5. Regarding the jvm services talk, you might check if CLOCK_MONOTONIC_COARSE isn’t sufficient for the cheap os time you are looking for (updated by the os HZ times a sec).

    • I need a milli-second granularity clock that’s very cheap. gettimeofday involves reading a largish structure, including some words twice to detect non-atomic access, plus a bunch of indirection layers to get to the basic structure. I used to get a 10% speed boost on the SpecJBB benchmark if I use shift & scale on the RDTSC, but in general the TSC isn’t stable enough to use for everyday Java work.


Leave a Reply

Your email address will not be published. Required fields are marked *