Actually it was something I’ve been wanting to do for a long time, to talk about an experience of how to design something from a green field using Java 8 sort of the experiences around that. But it also gave me the greatest opportunity to present a Doctor Strangelove theme talk. So who can pass that up right?
Harry: That was a tremendous opportunity and well done by the way.
Thank you, thank you. I am sure I broke all kind of copyright laws but I tried to keep it in a range of normalcy.
Harry: It’s in the interest of the common good, right?
Yes.
2. Tell us about lambdas in Java 8 and your experience with them?
They actually optimize very well, they give you another way of composing things to make the optimizer more happy with the code being able to optimize things. But they do have a few rough edges specifically around what lambda allocates and what doesn’t. It all happens to be around what it captures, which isn’t I guess that surprising, but it has even come to people who are very familiar with Java and Java 8, “Hey this allocates”. And when you are trying not to allocate and you are trying to be totally garbage free, you have yet to figure out how to get around it. So just hoisting logic out, doing things around that that’s really the key to making that so it doesn’t allocate so you still get all the benefit that you want you just may have to do things that normally you wouldn’t think about doing.
For us it was just experimenting, we found that there was garbage, they were obviously lambdas because they said lambda, and then looking at why would they allocate? And then sort of pairing it down to that it was what they were captured over and I mean again it wasn’t only after understanding what was going on, it wasn’t that surprising but if you are not thinking about it, there is no clue to clue you in that, it’s actually capturing, or actually there is the clue that it’s capturing but you don’t really link that to it has to allocate every time it’s called so the code may not be as clean as it needs to be, from what you normally think about, but there are simple fixes to that.
Yes, if you are capturing instead of actually having right at that spot having the lambda, you may have to actually make the lambda so that it is assigned when an object is constructed instead. And that keeps the allocation right there. But if the lambda doesn’t actually capture anything, then you are free to put it wherever it doesn’t allocate. So it forces you to think about things and we noticed this as well, if you know that it captures, do you really need to capture that state? Just asking that question sort of says “Well if I can figure out what I don’t have to capture then it’s not going to allocate”. It gives you a design potentially that is even better anyway. So that is what we noticed.
As detailed, as they want to and as detailed as they feel that they need to. In my case I actually like it, I like understanding what’s going on and let’s me look at design I wouldn’t have thought about any other way, but not all developers need to do that. And it’s an art to determine where you need to go deeper and where you need to apply mechanical sympathy, and everything else, and where you can sort of do whatever seams to be the most appropriate for the domain. An average person who is doing it if they need to squeeze out performance, then yes, looking at it and understanding how everything works can give you some great tools. But if you don’t have a performance target, then doing things a more naïve way and keeping up with whatever seams to be appropriate, that’s pretty fine. But I do think that as a profession, you don’t go to a chemist and ask them you don’t really know how a reaction works right?
Every chemist knows how a reaction works. Just like every programmer sort of knows how to do certain parts of algorithms. They may not know how to do them efficiently sometimes, sometimes they do, but as a discipline we are kind of in the alchemy stage, we tend to copy things that we don’t understand a lot of times, we tend to do a lot of other things that aren’t really disciplined as a discipline. But I think in the long run we’ll develop what is the appropriate depth for a beginner, an intermediate and a person who is advanced. And that just like other sciences, computer science will eventually get to that point where it’s about the algorithm, it’s about the platform, it’s about the best practices, and we’ll get there as a curriculum, as a discipline everything else. So, the short answer is, as a developer, go as deep as you feel you need to for what you’re doing. And if you want to go deeper, I would suggest going deeper, but only as much as you’re willing to put into it. There’s a lot of different things in life and if this isn’t something you don’t want to spend your time on, please don’t. You’d be much happier that way.
6. A path towards maybe digging a little bit deeper though is to start measuring everything?
Measurement is one of those things it’s incredibly difficult to refute. There’s a great quote you know “In God we trust; all others bring data” and it’s a quote by a guy who spent his life working on quality and it actually sums up a lot of the way I feel about certain things. I look at numbers are very hard to refute when they are put in context. They are easy to refute when they are out of context but when they are put in context and you measured and you have numbers they give you a solid foundation where things start to make much more sense. And it doesn’t feel as much like alchemy, feels a lot more like a science when you have numbers that you can look at and you can use those as to reason about.
7. You have a new product coming out, an open source project called Aeron?
Yes, myself and Martin Thompson, Richard Warburton, we’ve been working on something for a little while called Aeron which is a high throughput low latency open source messaging transporter. It’s been awesome working with Martin and Richard on this and it’s an example where protocols and wait free lock free data structures and things have really influenced one another. And we’ve developed something, which we think is pretty cool, and we want others to use it and see what it is. There is a sponsor for it who has been supporting the work, and that will be public knowledge shortly as well and we are really pretty proud of it. We found out a lot of different things about Java8 we’ve learnt a lot of warts about Java itself that even surprised people like Martin and Richard, and me as well, and it’s been a learning experience all around and we have a lot of things that we think the design can do that we think are pretty cool. And we solved some real world problems for people in the financial services space, sports and entertainment, logistics, lots of different places where this can apply.
8. Can you compare and contrast wait free and lock free?
Yes. One way to think about it or at least one way that I think about it is a wait free algorithm will pretty much finish within a certain time, number of instructions, things like that. Lock free is something where you are always making progress but you may not have a set schedule where something is going to finish. A perfect example would be you are sending on and looping on a position in memory and you are waiting for something else to change it, another thread. That can be lock free because you are continually making progress but it’s not wait free because you are not under the control of when that is going to be free, and it could take a while or it may not finish at all. So those are different, a lock free algorithm is often not wait free; wait free is actually harder, so if you look at it like a Venn diagram of the difficulty of finding out algorithms, you’ve got lock free, is one set, and wait free is another and sometimes they intersect. Actually it would be arguable whether you can have a wait free algorithm that is also lock free or not. That would be an interesting discussion, but I tend to think about them in that terms: is weight free a given guarantee of getting back to you, lock free doesn’t quite give you that but it does try to make progress.
9. As a user of Aeron what can I expect?
You can expect high throughput, you can expect low latency, and you can expect that there is low contention between different things within the protocol. So by definition if you have a stream which is a way of cutting up a communication channel that one stream will not contend on data from another stream so you should be able to have numbers of different streams, and they will be just fine with one another.
Harry: I’ve already determined the target of the communication. This isn’t a routing mechanism.
Not really. There are some aspects of it which are very much like TCP in that you have a listener, a receiver, and you have a sender who’s going to be sending to that and the listener knows what he is listening to and the sender knows what he is sending to. But there is also a reliable multi cast case where a receiver is listening to a stream of events that are just being sent and what’s kind of different is that this reliable multi cast implementation from the protocol perspective has built in flow control, so that’s very different, there’s really no other implementation that I know of that has built in flow control. There’s some congestion control but congestion control and flow control are quite different. So from that perspective you can have a multi cast sender who’s just sending out that as fast as the receiver can consume it.
10. That’s kind of a built in back pressure mechanism?
Yes. By the way this idea I have for about twenty years I just never had the opportunity to implement it.
Harry: That’s pretty cool.
Yes, it was very much something like “Oh yes this was going to be part of my dissertation”. And being able to pull it out and go “Ok, let’s see if this actually kind of works”. And it seams to work very well actually.
Harry: That must be a great feeling.
It is pretty cool.
Harry: Todd thanks for your time.
Thank you.