TSSJS Day 3

I want to cover two sessions from the third day:

The busy Java developer’s Guide to Scala

Ted Newman is definitely a charismatic presenter. With great passion he reviewed basic functionality of Scala DSL. Well Scala is a functional language and after the session I really want to learn it.

Performance Tuning a web shop with open source tools

Dr. Jeroen Borgers showed how performance improvement process can be done using Open Source tools. He was using JMeter (while I usually use LoadRunner) for load generation. Jprobe for profiling (I prefer YourKit BTW). JAMon for continuous monitoring (I used SiteScope commercial tool). For reporting purposes they wrote their own tool and placed on SourceForge (JaRep).

TSSJS Day 2

I want to cover 3 sessions on the secion day

Languages-Oriented Programming: Shifting Paradigms
Computer languages evolution enables us to pave over disturbing problems (e.g. GC as a mechanism to pave over error-prone memory allocation, Neal Ford introduced a very important observation.. One of the most powerful aspects in Java platform is the community and the amount of open source frameworks. This creates a new problem to pave over. Each framework has its own jargon and adapting this to the java language leads to a complicated syntax which usually is very wet (not DRY – Don’t Repeat Yourself). Niel offer the use of DSLs to approach this problem. In other words frameworks will be transformed to a carefully designed DSL. AntLR as a lexical analyzer and environments like Jetbrains MPS can help reaching this with less efforts.


Extreme Transaction Processing, Low latency and performance
John Davis a banking expert gave a startling session on design criteria in the online trading arena. In this world a 1ms delay in processing a message can lead to losses of $100M. As a result for example banks try to locate the trading infrastructure as close as possible the trading backbone (usually in London) in order to reduce latency. In addition GC can be a real problem we are used to think of GC taking 200ms as something reasonable but again it is x200 from the 1ms threshold. You do not want to loose money on GC. This leads to weird solutions such as restarting the VM before the first GC and redirecting to a different cluster member in the meanwhile. Another point mentioned is that traditional RDBMS are not capable of handling tens of thousands of transaction on a reasonable price. The solutions will be to use in memory databases or caching mechanisms (e.g. GigaSpaces, Oracle Coherence, Terracotta etc… )

Concurrency and High Performance
Kirk Pepperdine session had an important punch-line. Processors clock speed is stuck at the 3Ghz boundary and this situation is not likely to change in the near future. CPU vendors are going to achieve Moore’s law by doubling the number of cores every 18 months. This is a fact developers can’t afford to ignore. Leading to the inevitable conclusion (punch-line ahead) Is your application ready to double it’s concurrency in the next 18 months?

The inevitable delay

A professional blogger will never let this happen. I admit that as a newbie when my wife joined me I preferred traveling and not blogging… Here is a link to the pictures. When I came back to Israel I was dead tired. So I continue to write only now (I do not regret it though)

Yourkit 7.5 is released

Yourkit is my favorite profiler. It is a bit of old news but I am happy to hear that Yourkit 7.5 is released (on the 22-May-08). It includes of usability improvements and bug fixes. The most important thing I think is the CPU measurements for stack trace snapshots. It can actually show you which treads consume CPU before starting to profile. Previously I used intrnal tools for such purposes... I did not try this feature yet and I wonder if it can be used with out configuration of the profiler agent (great value for production)

TSSJS day 1

A: Beautiful

B: Who?

A: The City.

B: Which city?

A: Prague

B: So why don’t you say Prague? Why are you going around and around?

A: Well, since I have got here I have an unstoppable urge to stroll in the beautiful streets.

B: So why don’t you?

A: Well....

I have landed in Prague Yesterday in 08:45 directly into the conference. (Comment: Try to avoid these scenarios as much as you can, I have been dead tired all day long). To the conference I have arrived two hours late and missed the first two sessions :-(.

While I really want to share as much knowledge as I can I am reluctant of writing long descriptions and summaries on sessions. A lecture heard can enlighten one’s mind but it is hard to transfer the essence of this enlightenment to a blog . Therefore, I am going to share with you a single most important piece of information I took with me from sessions.

The two most effective sessions I did attend on day 1 are (Drums !!!!):

Monitoring Management and Troubleshooting in the Java SE6 Platform

Jean-Francois Denis from SUN gave a very interesting session on JDK 6 new JMX abilities and tools. The lecture which started with the very basics did move to more advanced issues. The most useful piece of information from my point of view is the VisualVM. A real open source lightweight Java profiler!!

Java Performance Tooling

Dr Holly Cummins from IBM is a very colorful person and a funny lecturer. She gave a nice introductory session on performance troubleshooting. Holly exposed me to the term ‘lock-bound’ which is a brilliant terminology for saying ‘Well we use locking mechanism extensively and there is a lot of contention on these locks… this is why our application sucks’. From this lecture I am have learned that IBM have set of nice free tools which one can use even if he is not using IBM JVM.Follow this link for more information.

TSSJS

Hi,
I am on my way to TSSJS. This is the first time I am attending this conference and I am really thrilled as I heard great deal about it.
I will update my blog during the conference whenever I will have something interesting to say :-)
If you attend the conference come and say hello :-)

I have a flight to catch....

Client side Memory Leaks IE and GWT - A practical guide

By now I guess that you read the previous post and you are eager to get some practical knowledge.
So I will summarize my knowledge regarding this issue. While I agree it is a bit shallow it is much better than nothing at all.
Tools like IESieve and IEdrip proven to be inefficient when coming to GWT leaks the code is too big for them and the transformation from Java to JS complicates things.
I will be more that delighted to be proven an idiot, if someone have a better (proven) approach please let me know.

Code Review
When coming to solve /prevent memory leaks the best way will always be code review. Hence I will give a list of guidelines for reviewing GWT code:
First list of guidelines Stating the obvious:

1. Avoid writing JSNI code. Google made quite a good job in writing "almost" leak free it is so easy to ruin it if you do not know what you are doing. Remember every JSNI code you write will lower your productivity.
2. Do not use the DOM.* methods (except the setStyle... which are safe) . Manipulating the DOM yourself will lead you directly toward a memory leak.
   

Second list of guidelines - less obvious

1. Static variables containing(even indirectly) references to widgets and dom objects may cause a leak.
2. According to Google it should not happen :-) but in some cases event listeners may leak. unregistered them when window unloads.

Lion in the desert approach
When code review by it self is insufficient, the desperate developer should try the following approach. As stated in the previous post when a memory leak in GWT occur the entire JavaScript is locked in the memory. This will lead to a huge memory leak (megabytes in large modules). This major drawback which forces us to deal with memory leaks is also our savior. Since the memory leak is so evident it is possible to defferentiate between cases where it is existant and cases where it is eliminated. Track the VM size of the IE process while refreshing the page for several times. If the VM size inceases dramatically you have got a memory leak. Vice versa, memory do not increase constantly memory leak is solved.
Saying that all you need to do is comment out pieces of code until memory leak is eliminated.

This process is not easy nor fun some tips to improve its effectiveness:

• Memory leaks are ilusive sometimes removing an irellevant piece of code will stop the memroy leak. As a result you should try to reach to the smallest peice of code which is still leaking before eliminating it. This will ensure you do not shoot at the wrong target .
• Work directly on javascript files. It takes some experitse to be able to understand what you are doing but it worth it. GWT comiplation phase is long and working directly on the JS file shortens the search cycle dramatically.

Thats all folks :-)
Enjoy