# jgit, MutableInteger vs AtomicInteger 2 messages from 2008-11-25 to 2008-11-25. Participants: Vasyl Vavrychuk, Shawn O. Pearce. Thread: https://gitlist.dev/t/16463 ## Vasyl Vavrychuk, 2008-11-25 13:54 Subject: jgit, MutableInteger vs AtomicInteger Message-ID: URL: https://gitlist.dev/e/loom.20081125T134459-650%40post.gmane.org ``` Hi, I've just started browsing jgit sources and an obvious question arise. I didn't found such question in mail list and decided to ask the community. I don't see reason behind creating own mutable integer container because we have java.util.concurrent.atomic.AtomicInteger with methods public final int get() public final void set(int i) And that is what we want. Regards, V. V. ``` ## Shawn O. Pearce, 2008-11-25 19:19 Subject: Re: jgit, MutableInteger vs AtomicInteger Message-ID: <20081125191947.GI2932@spearce.org> URL: https://gitlist.dev/e/20081125191947.GI2932%40spearce.org In-Reply-To: ``` Vasyl Vavrychuk wrote: > I've just started browsing jgit sources and an obvious question arise. > I didn't found such question in mail list and decided to ask the community. > > I don't see reason behind creating own mutable integer container because we > have java.util.concurrent.atomic.AtomicInteger with methods > public final int get() > public final void set(int i) > > And that is what we want. Eh, its sort-of what we want. The MutableInteger used in jgit is used instead of this C construct: int x; call_something(&x); call_something_else(&x); ... now use x ... In other words it is stack allocated, passed into methods for them to read and/or update, and then later used in the caller. AtomicInteger does in fact have get and set methods, providing what would seem to be the same operation. But if you read the source code you'll see that the get and set methods operate against a volatile int. IIRC the volatile tag requires that the JRE must not cache the value in a register. If you look again at how MutableInteger is used, we never touch the value outside of a single thread. The volatile tag on the field isn't necessary. It may actually make it harder for the JIT to produce tight machine code. Where we use MutableInteger is the depths of revision traversal and commit parsing, it *must* be fast. Also, there's the simple fact that I forgot about AtomicInteger, and it took me less time to code MutableInteger than it did to look to see if the JRE had something already. ;-) -- Shawn. ```