Chronon 3.7 released

Posted by Prashant Deva on April 14, 2013
    • Tweet

    Lets see what we have this time:
    1. Huge Bugfix for Mockito and Spring Framework

    Bug was caused by faulty code generation by the cglib library used by these frameworks. Both the Recorder and Unpacker have been updated to now work around this. If you were seeing a ClassCastException during recording or a ‘cannot browse to method’ during debugging it was due to this bug.

    2. Automatic toString() in Locals view


    A long time coming, but finally here!. Now when you click on an array or an object or a string, you will see its contents auto generated as a toString() in the Locals view. Note that this does not use the toString() method in your object though.

    3. Highlighting in Post Execution Logging View
    Post Execution Logging view highlights expressions in blue.

    4. ‘Event’ instead of ‘Time’ in the Debugger UI

    The Debugger UI now correctly uses the ‘event’ label everywhere instead of ‘time’ since the ‘time’ value was really an event counter that you were looking at not wall clock time. This also removes the confusion a lot of people had as to whether the ‘time’ value referred to actual clock time.

    Chronon graduates from Alchemist Accelerator

    Posted by Prashant Deva on April 3, 2013
      • Tweet


      Last week, Chronon Systems graduated from the second class of the Alchemist Accelerator, founded by Ravi Belani of Stanford and formerly of DFJ.

      The crowd loved what we had to show and I was surrounded by a mob afterwards!
      Some Press Coverage:
      • TechCrunch
      • Gigaom
        (Note: the funding figure listed for Chronon is incorrect)
      Being part of the Alchemist has been a great experience. We love our classmates and cant wait to see what they will accomplish. A big thanks to Ravi and the team.

      Chronon 3.6 – More goodies

      Posted by Prashant Deva on April 1, 2013
        • Tweet

        Back from Easter? Here are some goodies from us :

        Unpacker Improvements

        Should get rid of the ‘Cannot Browse to Method‘ messages.

        Support for JBoss Tools

        (version 3.6.5)

        JBoss Tools 4.0 onwards is now supported. You should now be able to record JBoss from within Eclipse.

        Debugger Goodies

        ‘Run To Method’ annotations
        Now when you open a recording, there is a ‘run to method’ annotation next to any method that was called atleast once.
        1. Hovering over the icon shows you the total number of calls to the method.


        2. Clicking on the icon will give you the option to ‘run to’ the method.


        Descriptions for Time Bookmarks
        Time Bookmarks now allow adding a comment alongside each time bookmark.
        Should make it much easier to remember why you put that bookmark in the first place!

        Chronon wins Eclipse Community Awards 2013 for Best Application

        Posted by Prashant Deva on March 27, 2013
          • Tweet


          In 2011, it was the ‘Hot New Product‘.
          In 2012, it was ‘Best Developer Tool‘.
          This year, 2013, keeping up with the annual tradition of winning at EclipseCon, we have won ‘Best Application‘!

          The application in this case is Chronon 4 ‘Ops’.

          They say 3rd time is the charm. Huge thanks to everyone in the Eclipse community for helping us win 3rd year in a row! We hope to continue delighting you with amazing software in the years to come :)

          Java 7 Bytecode Verifier: Huge backward step for the JVM

          Posted by Prashant Deva on March 25, 2013
            • Tweet

            The reason why the JVM is so popular and has so many languages, IDEs, profilers, debuggers, APMs and other wonderful tools is because the JVM bytecode is extremely simple. You can teach someone the pretty much the entire bytecode in an hour and the next they would be using the ASM framework and manipulating bytecode.

            Stack Frames: Feature turned Flaw

            Enter Stack Map Frames..
            Java 7 brings with it a new bytecode ‘feature’ called Stack Map Frames which is the most complicated and unnecessary addition to Java yet and which erodes any simplicity the JVM bytecode has enjoyed thus far.

            To be fair, Stack Maps were initially introduced in Java 6, but they were an optional part of the class file and every tool maker ignored them. However Java 7 makes them a compulsory part of bytecode, opening the can of worms described below.

            What are Stack Map Frames?
            The aforementioned simplicity of the Java Bytecode came from the fact that it hid away all the black art and gory details of compiler design inside the JVM’s JIT compiler, leaving programmers to deal only with a dead simple high level representation. You didn’t have to understand compiler theory terms like data flow or control flow analysis if you just wanted to inject some bytecode. However, Stack Map Frames make you do exactly that!

            Stack Map frames essentially require you to keep track of the exact ‘type’ of the local variable table and operand stack at every bytecode instruction. While in theory, this may sound simple, in practice it will make your pull your hair out.

            Consider the case of code like this and how the popular ASM framework generates Stack Map Frames:

            1. The ‘type’ of a at line 6 will need to be whatever the superclass of MyThis and MyThat is.

            2. You don’t really know the type hierarchy of the classes during runtime bytecode transformation

            3. Trying to use reflection to lookup the hierarchy can cause the said class to be loaded. This has a few flaws:

            1. It will cause its static class initializer to be loaded at a time completely unexpected by the programmer (leading to bugs in the application).
            2. Since the class is loaded during the transformation, your bytecode instrumentor will not be called when its loaded, and its bytecode wont be transformed.
            3. You can easily get a ClassNotFoundException due to different classloaders being used for sub and super classes.
            4. Also did I say mention you have to be an expert in data flow analysis to actually implement this.

            How complex you ask?
            1. The code to do the Data Flow Analysis for this is so complex that the ASM Framework has over a 1000 lines dedicated to just this and it took 2 versions to get it right. But even then the fundamental approach is flawed due to the problem of trying to find the ‘common superclass’.

            2. As an example, here is what a google search for Stack Map Frames shows for me:

            The top 10 results are pretty much all error messages. No mention of what stack map frames even are.

            3. Since the ‘common superclass’ approach used by the ASM Framework doesn’t really work, correct custom implementations are so complex and hard to get right that that for Chronon we skipped it altogether and run the jvm with a special switch (described below) that falls back to the old verifier.

            The bullshit and the flaw

            According to the JVM spec, this new ‘feature’ of the JVM allows the bytecode verifier to go a tiny bit faster since it doesn’t have to do all those type calculations itself, since they are already done during compile time.

            The above rationale is so bad and full of bullshit that it deserves to be classified as a design flaw of the JVM. Here is why:

            1. The Bytecode Verifier was never really a source of performance problems. The java verifier can be turned off entirely with a jvm switch, but most people don’t do it, cause there is really no huge performance issue related to the verifier. Remember the verifier is run only once each time a class is loaded, and at that time its the IO that takes up most of the time, not the verifier.
            2. Stack Maps don’t really get rid of the verifier. The verifier still exists and it still runs. Only a tiny portion of the verifier is now turned off.
            3. The verifier still has to have the code to run without stack maps. Remember older jvm versions didn’t require stack maps, and even with jvm 7 a special jvm flag allows users to switch back to the old verification method. Thus the code to do the verification without stack map still exists and hasn’t really cut down the complexity of the JVM for the JVM designers either. They have to maintain 2 versions of the verifier for pretty much forever. Nobody wins in this game.
            4. Pre Java 7, there was one implementation for checking the type of the variables and stack at every instruction, and it was in the JVM, written by hard core compiler designers who know how to write efficient compilers. Now, that still needs to exist but every bytecode manipulator has to write his own implementation, but they are not compiler designers and it takes away time from writing the real application code. We end up with tons of different, inefficient, buggy implementations which do no good to the users, toolmakers or the java ecosystem has a whole.
            5. The whole ‘faster’ verification stuff is hogwash. Today almost every single application runs with some form of bytecode instrumentation. If you use Spring AOP, EclipeLink or tools like JRebel, Chronon, YourKit, NewRelic or basically any popular java tool or framework, your bytecode will be instrumented. Since the bytecode is instrumented (and sometimes multiple times), the stack maps will have to be generated during runtime anyway (defeating the whole purpose of the new verifier), and they will be generated by those buggy, and highly inefficient generators written by people who are not compiler designers.

            Bottom line: The new verifier resuls in slower, more complex and buggier code.


            The addition of Stack Map Frames only results in a net negative to the Java community and should be abolished.

            I propose the following:

            1. Always use -XX:-UseSplitVerifier the flag when running JVM 7. It will disable the new verifier which requires the need for Stack Frames.
            2. The ASM Framework needs to have another another algorithm that allows simple additions within the scope of a single basic blocks which don’t require recalculation of class hierarchy at runtime.
            3. Lastly, we should petition Oracle to make Stack Maps optional for Java 8 and above. This will preserve the currently generated code by the java 7 compiler, but it will free the world from a completely broken design and unnecessary bunch of complexity.

            Apparently Oracle is deprecating the -XX:-UseSplitVerifier flag in Java 8, which will make the this workaround impossible and have us forever stuck with stack map frames :(

            Comment on bug 8009595 to prevent Oracle from doing so.

            No Compilation

            Posted by Prashant Deva on March 24, 2013
              • Tweet

              I absolutely love it when a product completely obviates a need for certain process/step to the the point that you never even have to think about it.

              This is why I love Eclipse over all other IDEs. In Eclipse, your project is always compiled. In fact there isn’t even a compile button in the UI. Just click ‘Save’ and that’s it! If you have any errors in any of your thousands of source files after your most recent edit, just the act of hitting save will make it appear.

              While other IDEs seem to be moving in this direction, none has an implementation currently that works as well as Eclipse.

              For this reason alone, I find Eclipse to be heads above the rest. I never have to think about the ‘compilation’ step.

              Chronon 3.5 – Java 7 now supported

              Posted by Prashant Deva on March 10, 2013
                • Tweet

                Its taken us a while, but Java 7 support is finally here!

                If you use the Chronon Recording Server, you have to add one extra argument (alongside the jaavaagent arguments): -XX:-UseSplitVerifier

                Note that we don’t support other dynamic jvm languages like Groovy, etc, so the invokedynamic instruction in the jvm (which is used by these lanagues, not Java) is not supported by Chronon.

                Download now:

                Chronon 3.2 released

                Posted by Prashant Deva on
                  • Tweet

                  We usually update Chronon so often (almost every few days) that when we even sometimes we do a traditional company style update, which takes a few weeks, our users get a little upset :-)

                  But not to worry, because version 3.2 is finally here!

                  We got delayed a bit with this one because some of the bugfixes and performance enhancements we wanted to make needed us to change the recording file format in a way that broke compatibility with previous versions of the debugger. Thus we combined a bunch of fixes/updates into one big update. Here is what it contains:

                  Unpacker Performance and File size improvements

                  Both the file size and time taken to unpack have been reduced by almost 20%. Enjoy a faster Chronon experience!

                  Bug fixes

                  Tons of them. If you were running into bugs in the debugger, you couldn’t be anymore. If you use the Chronon Recording Server, make sure to update the Chronon Controller since this one contains a critical bugfix.

                  Enjoy the new Chronon and rest assured our future updates will not take this long.


                  Recording Server now runs with just a double click

                  Posted by Prashant Deva on March 9, 2013
                    • Tweet

                    The Chronon Recording Server installation was quite tedious for some users since it involved configuring and installtaing multiple components and needed a standalone container for deploying recordingserver.bat.

                    We have made things much simpler now with version

                    Just double click on start.bat( or to start running the Recording Server and Chronon Controller processes.

                    Full details here:


                    Dark Eclipse theme

                    Posted by Prashant Deva on December 13, 2012
                      • Tweet

                      Intellij IDEA recently launched with a cool new Dark theme, so I set about to find something equivalent for my beloved Eclipse.


                      Apparently it didn’t take me too long. All you need to do is :

                      1. Make sure you have the latest version of Eclipse, ie, Juno

                      Sorry but previous versions dont exactly support theming. 

                      2. Download the ‘Dark Juno’ theme

                      This will change the color of all eclipse view and toolbars to a dark theme. However we still have to change the color theme of the editor.

                      3. Get the Eclipse Color Themes plugin

                      Install a dark theme for the editor from there. I personally recommend ‘Oblivion’. It is also the most popular theme on the site.

                      And tada! You now have ‘Dark Eclipse’! Granted the theming is a bit rough around the edges but you didn’t have to fiddle with your OS color schemes and takes only minutes to setup. You end up with a nice, eye soothing color palette for an application you will be looking at all day :)


                      « Previous 1 2 3 4 5 6 7 8 9 10 11 Next »