jgit, MutableInteger vs AtomicInteger

jgit, MutableInteger vs AtomicInteger

[Vasyl Vavrychuk]

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.

Re: jgit, MutableInteger vs AtomicInteger

[Shawn O. Pearce]

Vasyl Vavrychuk <vvavrychuk@gmail.com> 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.