Re: [JGIT] Re: blinking test WindowCacheGetTest.testCache_TooSmallLimit

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

 



Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx> wrote:
> > Constantine Plotnikov <constantine.plotnikov@xxxxxxxxx> wrote:
> > > The test WindowCacheGetTest.testCache_TooSmallLimit sometimes fails
> > > (on less than third of runs on Windows) with the following stacktrace:
> 
> Could it be threading-related (cache). I've never seen it on the machine where I build for
> the update site and it is a single core machine, but I "this" machine that has two cores it happens, not
> as offen as 1/6, but enough to annoy me a bit, perhaps 1/20. If it is related to bad synchronization
> it should happen more often the more cores you have.

No, its not threading related.  I think I at least partially
understand what is going on.

WindowCache's base class, OffsetCache, does evictions by randomly
selecting a starting point in the table, and then scanning at most
evictBatch segments of the table before giving up.

When testCache_TooSmallLimit needs to access another window it must
first evict the current window, as the cache size is set to exactly
1 window in this test.

If the RNG selects the starting point at an empty segment, and
evictBatch is smaller than the total table size, we may not scan
the segment which contains an open window.  The eviction stops
before it actually expires an entry, and the cache is permitted to
allocate more than it was supposed to.

The test failure is random due to two different things going on:

 - The starting point for eviction is determined by an RNG, whose
   seed is initialized randomly at the start of the tests.

 - The position of a given entry in the segment table is partially
   determined by the System.identityHashCode of the PackFile instance
   it is being loaded for.  Since that differs as the JVM allocs
   and reclaims objects, there is some randomness caused by the
   order tests are run in.

However, in this test I'm still not quite sure why its failing,
because evictBatch is equal to the table size (both 2), so any
eviction here should have scanned the full table.

-- 
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]