|[jgit-dev] non-static WindowCacheConfig?|
We could hold a final AtomicReference to the cache in the ObjectDatabase. Then EGit can change what the ref points at to change the cache and all impacted repos change to match at the same time.On May 17, 2014 9:12 AM, "Shawn Pearce" <spearce@xxxxxxxxxxx> wrote:
So this was about two things.
First was memory management. The JVM heap is finite and JGit holds a lot of data in the cache. We had to unify it over all threads and instances to ensure we used a finite fraction of the JVM heap as the heap cannot grow once the application is running.
The second was performance. JGit makes a lot of cache lookups and the static method call is faster than a virtual method dispatch. But in more recent time I think that has been destroyed by the cache using a volatile field to reference itself.
I think we could change the repository code to have the cache in the ObjectDatabase as a field and modify the RepositoryBuilder to have a new setter to set the cache, with the default being the one from the static.
That would change cache lookup to be an instance field get rather than a volatile read, which should be no more costly.
This would break EGit changing the cache while repository is open. We would need to have EGit reopen the repos after a cache change. And some unit tests in JGit change the cache while the repo is open.
But I think its workable.
One thing I want to do is offer different cache backings like one using hard ref instead of soft ref, or an out of process cache that has native C code to accelerate cache lookup and data decompression.On May 15, 2014 2:45 PM, "Roberto Tyley" <roberto.tyley@xxxxxxxxx> wrote:
Is the static-ness of WindowCacheConfig a valuable thing (perhaps in terms of perf/mem usage?) or would there be any mileage in me working on a patch to allow it to be scoped to something non-JVM-wide (for instance, just to an instance of a Repository?).The specific case where this is bothering me is with testing the BFG - I have a suite of tests, one which deals with over-sized commit objects that require an increased value for streamFileThreshold - other tests in the suite set streamFileThreshold to a much lower value of 1MB. In principle all the tests could run happily and concurrently in the same JVM (ie quickly), but the unfortunate static nature of the setting means that the tests all step over each other's value for it, causing frequent failures in the Large-Commit-Object-Test :(The simplest way to get this going is slow: just fork a new JVM for each test. Bleaugch. I'd much rather remove the static nature of this config. Apart from a certain potential for this to break API compatibility, would it be likely I could get this change accepted into JGit master?best regards,Robertohttps://github.com/rtyley/bfg-repo-cleaner/blob/92343a4/bfg/src/test/scala/com/madgag/git/bfg/cli/MainSpec.scala#L101
jgit-dev mailing list
Back to the top