I added an abstraction for obtaining access to the graph in preparation for creating a main memory implementation of the GAS API.

See #629

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7342 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Refactored to abstract everything except for the GASRunner completely away from the IIndexManager and Journal.  

See #629

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7343 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Updated GAS properties for execution on mac mini environment.


git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7344 8f7bc0f5-282e-0410-95e3-8d296e9bb460
replace Collections.emptyIterator() with the CTC EmptyIterator. The Collections class method was not  introduced until 1.7.

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7345 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Refactored to add link weight support (still need the RDR parser to use this except in SIDs mode and still need to co-locate that SIDs with the ground triples in the SPO(C) and OSP(C) indices).

Refactored nearly everything to abstract out a concrete implementation that does not depend on the bigdata backend.  The next step will be to replace the use of IV and ISPO throughput with openrdf Value and openrdf Statement.  We can then easily implement a variant over the MemorySail for openrdf (or over some custom classes that are optimized for the GAS traversal patterns).  That will give us a fully functioning implementation outside of the core bigdata code base.  We can then isolate the remaining dependencies (striterator and a few other items) and create an Apache 2 package for the APIs and the non-bigdata specific implementation.

See #629

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7346 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Added a managed array abstraction and replaced the static frontier implementation with that abstraction.

The code paths that compact and sort the frontier have been modified to reuse an array that grows as necessary.  This should reduce the overhead associated with memory allocation for the frontier.

I still need to optimize this for the thread-local frontier.

I still need to use a parallel sort for the frontiers (other than the thread-local one, which already breaks the sort into N threads since each per-thread frontier is sorted independently).

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7353 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Modified the thread-local scheduler to reuse the same backing array to sort the thread-local frontier in each round.


git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7354 8f7bc0f5-282e-0410-95e3-8d296e9bb460
javadoc

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7355 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Deprecated the old StaticFrontier class.

Refactored the new StaticFrontier2 class so that the time required to copy in the new frontier and the time to sort it show up clearly in the profiler and can be clearly distinguished.

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7356 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Modified StaticFrontier2 to clear out any non-null elements in the backing array.  This addresses a GC leak during the computation.

Modified TLScheduler to clear the map of per-thread schedulers rather than clearing each per-thread scheduler. This is a big hot spot.

See #629

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7357 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Optimize the thread local scheduler in a new implementation that defers the eliding of duplicate vertices in the frontier until the next round.  This should reduce the time in between rounds (and the time in which the code is single threaded) significantly.

@see #629

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7358 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Modified IV to implement Value.  All concrete IV implementations already implement Value.  I have run TestLocalTripleStore, TestBigdataSailWithQuads, and ast.eval.TestAll, and com.bigdata.rdf.TestAll with this change.  Everything is fine.

I had to modify SearchInSearchServiceFactory to clarifiy a method call which became ambiguous with this change (compiler error).

I had to add a missing method (Value.stringValue()) to TestEncodeDecodeKeys.

This change was made to support #629 (Graph mining API).

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7359 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Added @Override annotations on SPO

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7360 8f7bc0f5-282e-0410-95e3-8d296e9bb460
removed import from outside of the bigdata-client JAR

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7362 8f7bc0f5-282e-0410-95e3-8d296e9bb460
updated package documentation


git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7363 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Refactored the GAS API to use the openrdf model classes for vertices (Value) and edges (Statement).  

The concrete implementation is still based on the bigdata indices and the bigdata AbstractTripleStore.  However, it should now be easy to create an implementation based on the MemorySail.

Performance should not change with this commit since the underlying implementation is essentially unchanged.  We still use IV and ISPO objects, but those implement Value and Statement.

All tests pass.

The local performance test provides the same results and performance as the previous committed version.

See #629 (Graph Mining API)

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7364 8f7bc0f5-282e-0410-95e3-8d296e9bb460
The implementation to date has incorrectly failed to consider a bnode to be a vertex.  All of the baselines will have to be recomputed (this has a large effect for the data set we have been using since bnodes are quite common in the foaf crawl.)

See #629 (Graph Mining API)

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7365 8f7bc0f5-282e-0410-95e3-8d296e9bb460
The Jetty-based CHSScheduler is close to the performance of the java.util.concurrent.ConcurrentHashMap based CHMScheduler.

{{{
TOTAL: analytic=BFS, nseed=217, nsamples=1000, nthreads=4, bufferMode=DiskRW, scheduler=CHMScheduler, edges(kb)=444224, stats(total)=nrounds=22834, fontierSize=39967201, ms=145801, edges=93559787, teps=641694
TOTAL: analytic=BFS, nseed=217, nsamples=1000, nthreads=4, bufferMode=DiskRW, scheduler=CHSScheduler, edges(kb)=444224, stats(total)=nrounds=22834, fontierSize=39967201, ms=148106, edges=93559787, teps=631706
}}}

Since the CHSScheduler does not dominate the CHMScheduler and since it creates a dependency on jetty, the CHScheduler is being removed.

See #629 (Graph Mining API)

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7366 8f7bc0f5-282e-0410-95e3-8d296e9bb460
applying patch from ticket #701

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7367 8f7bc0f5-282e-0410-95e3-8d296e9bb460
Allowing override of the journal file name from the command line in the GASRunner.

See #629

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7368 8f7bc0f5-282e-0410-95e3-8d296e9bb460