Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Wednesday, April 10, 2013

BDD vs. TDD

Behavior Driven Development vs. Test Driven Development

Excellent explanation of why we do not write our tests tied to the implementation of the solution. If you are developing in the Java world, and want to try out BDD, checkout JBehave. BDD vs TDD (explained)


Another great video on the topic. Behavior Driven Development

Writing software in an organisation or for ourselves, many people feel that they "should" somehow be doing Test Driven Development (TDD) because "everybody else" is and it's cool, somewhere between necessary and useful and they heard testing was good. When informed that must of TDD isn't about testing (despite the name!), confusion reigns.

Behaviour Driven Development is a different way of approaching the "how to validate your code" problem.
TDD You are actually specifying what should be happening and not testing what is happening.Instead of thinking about what is the next function I need to implement think about what is the next feature I need to implement.

Sunday, December 23, 2012

JVM Fixed Upper Limit for Memory Usage


Well, there is a paper from Sun (eh, Oracle) that explains a lot about GC internals: oracle.com/technetwork/java/gc-tuning-5-138395.html . There it says By default, the virtual machine grows or shrinks the heap at each collection to try to keep the proportion of free space to live objects at each collection within a specific range. (section 4.1). So it's not really "full GC before heap increase", rather it's "heap increase if full GC does not free up enough"

http://stackoverflow.com/questions/3358328/why-does-the-sun-jvm-have-a-fixed-upper-limit-for-memory-usage-xmx

Why is memory management so visible in Java VM?


Java gives you a bit more control about memory -- strike one for people wanting to apply that control there, vs Ruby, Perl, and Python, which give you less control on that. Java's typical implementation is also very memory hungry (because it has a more advanced garbage collection approach) wrt the typical implementations of the dynamic languages... but if you look at JRuby or Jython you'll find it's not a language issue (when these different languages use the same underlying VM, memory issues are pretty much equalized). I don't know of a widespread "Perl on JVM" implementation, but if there's one I'm willing to bet it wouldn't be measurably different in terms of footprint from JRuby or Jython!

Python/Perl/Ruby allocate their memory with malloc() or an optimization thereof. The limit to the heap space is determined by the operating system rather than the VM, so there's no need for options like -Xmxn. Also, the garbage collection is simpler, based mostly on reference counting. So there's a lot less to fine-tune.

Furthermore, dynamic languages tend to be implemented with bytecode interpreters rather than JIT compilers, so they aren't used for performance-critical code anyway.

"So why does the JVM have (need?) a ceiling at all? Why can't it be flexible enough to request more memory from the OS when the need arises?" The Sun JVM can be easily configured to do just that. It's not the default because you have to be careful that your process doesn't cause the OS to thrash



Changing JVM is not a panacea. You can get new unexpected issues (e.g. see an article about launching an application under 4 different JVM).

You can have a class leak (e.g. via classloaders) that mostly often happen on redeploy. Frankly, I've never saw working hot redeploy on Tomcat (hope to see one day).
You can have incorrect JVM paramaters (e.g. for Sun JDK 6 64 bits -XX:+UseParNewGC switch leads to leak PermGen segment of memory. If you add additional switches: -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled-XX:+CMSPermGenSweepingEnabled the situation will be resolved. Funny, but I never met above mentioned leak with Sun JDK 6 32 bits). Link to an article "Tuning JVM Garbage Collection for Production Deployments".
PermGen chunk can be not enough to load classes and related information (actually that most often happens after redeploy under Tomcat, old classes stay in memory and new ones are loading)

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

http://stackoverflow.com/questions/1009042/what-free-jvm-implementation-has-the-best-permgen-handling

http://stackoverflow.com/questions/2550529/why-is-memory-management-so-visible-in-java-vm

http://java.dzone.com/articles/tale-four-jvms-and-one-app

http://java.dzone.com/articles/classloaderlocal-how-avoid -- Great Article!!