(At risk of being flamed here...) Totally! Since working with other JVM languages, I've definitely found myself learning a lot more about the Java memory model, optimisation and GC behaviour.
Features like first-class functions and immutability tend to produce a much higher churn in short lived objects than you'll find in a "typical" Java program, so it helps to better understand the exact nature of generational garbage collection and performance tuning strategies. I've also formed a better understanding of how to optimise around the costs of primitive boxing. This is absolutely knowledge that has proven useful when I have to go back and work with Java code. On 30 September 2010 15:24, Chris Adamson <[email protected]> wrote: > On Sep 30, 9:36 am, Carl Jokl <[email protected]> wrote: > > The way I see it is that even with the Computer Science background and > > understanding O/S memory allocation models and how C/C++ allocates > > memory as well as Stack and Heap memory theory the errors still happen > > because I am human and miss things sometimes. It is all good and well > > when the program flow is simple enough for the allocations and > > deallocations to be easy to see and in a straightforward logic. The > > more complex the application gets the more complicated it becomes to > > manage the memory correctly. Both feeing memory which something is > > still using or not freeing it leads to problems. > > I started reading (maybe I should get the whole thing) a whole book on > Kindle about "Memory as a Programming Concept in C and C++". Like > you've pointed out, the problem in complex applications is knowing > when it's OK to free something, especially since the consequences of > freeing something prematurely are disastrous (usually a crash). Since > so many people work with C and C++, there are standard solutions, such > as reference-counting, but these introduce their own complexities. > For a lot of people, garbage collection hits a sweet spot: pretty easy > to get right, not too expensive in terms of memory or CPU. > > > Maybe I should try Assembler just for kicks....I like pain. > > Doing anything radically outside your comfort zone will help you think > more flexibly -- that was one of Dick's points in the other thread. > Assembly will let you think more concretely about the interaction of > the CPU and RAM. Most people are headed in the other direction, > adding more layers of abstraction. I think it's helpful to have spent > at least a little time right on the iron. > > --Chris > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
