UUM-147204
Fixed in 6000.7.0a4Mentioned in 24 release notes.
First fixed in 6000.7.0a4 (Aug 6, 2026); relisted in 23 later releases.
| Version | Section | Risk | Impact | Note |
|---|---|---|---|---|
| 6000.7.0b8 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0b8 | Fixes Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behavior from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. | |
| 6000.7.0b7 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0b7 | Fixes Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behavior from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. | |
| 6000.7.0b6 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0b6 | Fixes Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behavior from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. | |
| 6000.7.0b5 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0b5 | Fixes Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behavior from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. | |
| 6000.7.0b4 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0b4 | Fixes Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behavior from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. | |
| 6000.7.0b3 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0b3 | Fixes Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behavior from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. | |
| 6000.7.0b2 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0b2 | Fixes Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behavior from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. | |
| 6000.7.0b1 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0b1 | Fixes Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behavior from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. | |
| 6000.7.0a6 | Fixes Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behavior from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. | |
| 6000.7.0a6 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0a6 | Fixes Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behavior from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. | |
| 6000.6.0f1 | Fixes Performance Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. (UUM-147204) First seen in 6000.6.0a8. | |
| 6000.6.0f1 | Fixes Performance Test Framework | Fix | Measure.Method().GC() again forces a full garbage collection immediately before each timed region, restoring the behaviour from before the switch to the ProfilerRecorder API. Without it, a collection triggered by the measured code's own allocations lands inside the timed region and shows up as periodic spikes across the samples. As before: this only happens when GC() is specified; warmup and probing iterations are not affected; and because SetUp/CleanUp cause each of the IterationsPerMeasurement inner executions to be timed separately, that combination gets one collection per inner execution rather than one per sample, which makes it considerably slower. Reported times for allocating methods measured with GC() will change, generally becoming lower and more stable, so baselines recorded since 3.2.1 are not comparable. (UUM-147204) First seen in 6000.6.0a8. | |
| 6000.7.0a5 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0a4 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. | |
| 6000.7.0a4 | Fixes Test Framework | Fix | Profiler marker recorders used by Measure.Method now start when the measured iterations begin instead of when ProfilerMarkers() is called, so warmup and probing iterations no longer contribute to the reported marker values or add sample collection overhead to those phases. |