Du kannst nicht mehr als 25 Themen auswählen Themen müssen mit entweder einem Buchstaben oder einer Ziffer beginnen. Sie können Bindestriche („-“) enthalten und bis zu 35 Zeichen lang sein.

GcTestCase.java 3.8KB

Update bitmap selection throttling to fully span active branches. Replace the “bitmapCommitRange” parameter that was recently introduced with two new parameters: “bitmapExcessiveBranchCount” and “bitmapInactiveBranchAgeInDays”. If the count of branches does not exceed “bitmapExcessiveBranchCount”, then the current algorithm is kept for all branches. If the branch count is excessive, then the commit time for the tip commit for each branch is used to determine if a branch is “inactive”. "Active" branches get full commit selection using the existing algorithm. "Inactive" branches get fewer bitmaps near the branch tips. Introduce a "contiguousCommitCount" parameter that always enforces that the N most recent commits in a branch are selected for bitmaps. The previous nextSelectionDistance() algorithm created anywhere from 1-100 contiguous bitmaps at branch tips. For example, consider a branch with commits numbering 0-300, with 0 being the most recent commit. If the most recent 200 commits are not merge commits and the 200th commit was the last one selected, nextSelectionDistance() returned 100, causing commits 200-101 to be ignored. Then a window of size 100 was evaluated, searching for merge commits. Since no merge commits are found, the next commit (commit 0) was selected, for a total of 1 commit in the topmost 100 commits. If instead the 250th commit was selected, then by the same logic commit 50 is selected. At that point nextSelectionDistance() switches to selecting consecutive commits, so commits 0-50 in the topmost 100 commits are selected. The "contiguousCommitCount" parameter provides more determinism by always selecting a constant number or topmost commits. Add an optimization to break out of the inner loop of selectCommits() if all of the commits for the current branch have already been found. When reusing bitmaps from an existing pack, remove unnecessary populating and clearing of the writeBitmaps/PackBitmapIndexBuilder. Add comments to PackWriterBitmapPreparer, rename methods and variables for readability. Add tests for bitmap selection with and without merge commits and with excessive branch pruning triggered. Note: I will follow up with an additional change that exposes the new parameters through PackConfig. Change-Id: I5ccbb96c8849f331c302d9f7840e05f9650c4608 Signed-off-by: Terry Parker <tparker@google.com>
vor 8 Jahren
Update bitmap selection throttling to fully span active branches. Replace the “bitmapCommitRange” parameter that was recently introduced with two new parameters: “bitmapExcessiveBranchCount” and “bitmapInactiveBranchAgeInDays”. If the count of branches does not exceed “bitmapExcessiveBranchCount”, then the current algorithm is kept for all branches. If the branch count is excessive, then the commit time for the tip commit for each branch is used to determine if a branch is “inactive”. "Active" branches get full commit selection using the existing algorithm. "Inactive" branches get fewer bitmaps near the branch tips. Introduce a "contiguousCommitCount" parameter that always enforces that the N most recent commits in a branch are selected for bitmaps. The previous nextSelectionDistance() algorithm created anywhere from 1-100 contiguous bitmaps at branch tips. For example, consider a branch with commits numbering 0-300, with 0 being the most recent commit. If the most recent 200 commits are not merge commits and the 200th commit was the last one selected, nextSelectionDistance() returned 100, causing commits 200-101 to be ignored. Then a window of size 100 was evaluated, searching for merge commits. Since no merge commits are found, the next commit (commit 0) was selected, for a total of 1 commit in the topmost 100 commits. If instead the 250th commit was selected, then by the same logic commit 50 is selected. At that point nextSelectionDistance() switches to selecting consecutive commits, so commits 0-50 in the topmost 100 commits are selected. The "contiguousCommitCount" parameter provides more determinism by always selecting a constant number or topmost commits. Add an optimization to break out of the inner loop of selectCommits() if all of the commits for the current branch have already been found. When reusing bitmaps from an existing pack, remove unnecessary populating and clearing of the writeBitmaps/PackBitmapIndexBuilder. Add comments to PackWriterBitmapPreparer, rename methods and variables for readability. Add tests for bitmap selection with and without merge commits and with excessive branch pruning triggered. Note: I will follow up with an additional change that exposes the new parameters through PackConfig. Change-Id: I5ccbb96c8849f331c302d9f7840e05f9650c4608 Signed-off-by: Terry Parker <tparker@google.com>
vor 8 Jahren
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126
  1. /*
  2. * Copyright (C) 2012, Christian Halstrick <christian.halstrick@sap.com> and others
  3. *
  4. * This program and the accompanying materials are made available under the
  5. * terms of the Eclipse Distribution License v. 1.0 which is available at
  6. * https://www.eclipse.org/org/documents/edl-v10.php.
  7. *
  8. * SPDX-License-Identifier: BSD-3-Clause
  9. */
  10. package org.eclipse.jgit.internal.storage.file;
  11. import java.io.IOException;
  12. import org.eclipse.jgit.internal.storage.file.GC.RepoStatistics;
  13. import org.eclipse.jgit.junit.LocalDiskRepositoryTestCase;
  14. import org.eclipse.jgit.junit.RepositoryTestCase;
  15. import org.eclipse.jgit.junit.TestRepository;
  16. import org.eclipse.jgit.junit.TestRepository.CommitBuilder;
  17. import org.eclipse.jgit.lib.AnyObjectId;
  18. import org.eclipse.jgit.revwalk.RevCommit;
  19. import org.eclipse.jgit.revwalk.RevWalk;
  20. import org.junit.After;
  21. import org.junit.Before;
  22. public abstract class GcTestCase extends LocalDiskRepositoryTestCase {
  23. protected TestRepository<FileRepository> tr;
  24. protected FileRepository repo;
  25. protected GC gc;
  26. protected RepoStatistics stats;
  27. @Override
  28. @Before
  29. public void setUp() throws Exception {
  30. super.setUp();
  31. repo = createWorkRepository();
  32. tr = new TestRepository<>(repo, new RevWalk(repo),
  33. mockSystemReader);
  34. gc = new GC(repo);
  35. }
  36. @Override
  37. @After
  38. public void tearDown() throws Exception {
  39. super.tearDown();
  40. }
  41. /**
  42. * Create a chain of commits of given depth.
  43. * <p>
  44. * Each commit contains one file named "a" containing the index of the
  45. * commit in the chain as its content. The created commit chain is
  46. * referenced from any ref.
  47. * <p>
  48. * A chain of depth = N will create 3*N objects in Gits object database. For
  49. * each depth level three objects are created: the commit object, the
  50. * top-level tree object and a blob for the content of the file "a".
  51. *
  52. * @param depth
  53. * the depth of the commit chain.
  54. * @return the commit that is the tip of the commit chain
  55. * @throws Exception
  56. */
  57. protected RevCommit commitChain(int depth) throws Exception {
  58. if (depth <= 0)
  59. throw new IllegalArgumentException("Chain depth must be > 0");
  60. CommitBuilder cb = tr.commit();
  61. RevCommit tip;
  62. do {
  63. --depth;
  64. tip = cb.add("a", "" + depth).message("" + depth).create();
  65. cb = cb.child();
  66. } while (depth > 0);
  67. return tip;
  68. }
  69. /**
  70. * Create a chain of commits of given depth with given number of added files
  71. * per commit.
  72. * <p>
  73. * Each commit contains {@code files} files as its content. The created
  74. * commit chain is referenced from any ref.
  75. * <p>
  76. * A chain will create {@code (2 + files) * depth} objects in Gits object
  77. * database. For each depth level the following objects are created: the
  78. * commit object, the top-level tree object and @code files} blobs for the
  79. * content of the file "a".
  80. *
  81. * @param depth
  82. * the depth of the commit chain.
  83. * @param width
  84. * number of files added per commit
  85. * @return the commit that is the tip of the commit chain
  86. * @throws Exception
  87. */
  88. protected RevCommit commitChain(int depth, int width) throws Exception {
  89. if (depth <= 0) {
  90. throw new IllegalArgumentException("Chain depth must be > 0");
  91. }
  92. if (width <= 0) {
  93. throw new IllegalArgumentException("Number of files per commit must be > 0");
  94. }
  95. CommitBuilder cb = tr.commit();
  96. RevCommit tip = null;
  97. do {
  98. --depth;
  99. for (int i=0; i < width; i++) {
  100. String id = depth + "-" + i;
  101. cb.add("a" + id, id).message(id);
  102. }
  103. tip = cb.create();
  104. cb = cb.child();
  105. } while (depth > 0);
  106. return tip;
  107. }
  108. protected long lastModified(AnyObjectId objectId) {
  109. return repo.getFS()
  110. .lastModifiedInstant(repo.getObjectDatabase().fileFor(objectId))
  111. .toEpochMilli();
  112. }
  113. protected static void fsTick() throws InterruptedException, IOException {
  114. RepositoryTestCase.fsTick(null);
  115. }
  116. }