Re: jgit, MutableInteger vs AtomicInteger

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Vasyl Vavrychuk <vvavrychuk@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux