Bitmap builder: actually compress EWAH bitmaps in memory

For construction performance each new EWAHBitmap is allocated at the
roughly worst-case size the bitmap would need if all of the words must
be literal and no run length compression is available.  In practice
this is far larger than is required, wasting heap memory while the
bitmaps are computed.

Trim down each bitmap to its minimum required size. This copies the
internal array to a new smaller array, allowing the GC to reclaim the
prior larger array for reuse.

A single bitmap of 5.2M bits is only 79 KiB of memory without this
trim call but 15,000 such bitmaps is 1.1 GiB. Trimming can help fit
a larger number of bitmaps during processing.

Change-Id: I2bd19a786189db5b01c4c96f209b83de50e10c3b

org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/file/PackBitmapIndexBuilder.java

@@ -115,6 +115,10 @@ public class PackBitmapIndexBuilder extends BasePackBitmapIndex {
 						JGitText.get().badObjectType, String.valueOf(type)));
 			}
 		}
+		commits.trim();
+		trees.trim();
+		blobs.trim();
+		tags.trim();
 	}
 
 	private ObjectToPack[] sortByOffset(List<ObjectToPack> entries) {
@@ -168,6 +172,7 @@ public class PackBitmapIndexBuilder extends BasePackBitmapIndex {
 	 */
 	public void addBitmap(
 			AnyObjectId objectId, EWAHCompressedBitmap bitmap, int flags) {
+		bitmap.trim();
 		StoredBitmap result = new StoredBitmap(objectId, bitmap, null, flags);
 		getBitmaps().add(result);
 		byAddOrder.add(result);