kezhuw commented on a change in pull request #15039:
URL: https://github.com/apache/flink/pull/15039#discussion_r584090439
##########
File path:
flink-runtime/src/test/java/org/apache/flink/runtime/metrics/util/MetricUtilsTest.java
##########
@@ -180,21 +241,54 @@ public MetricGroup addGroup(String name) {
// check memory usage difference multiple times since other tests may
affect memory usage as
// well
for (int x = 0; x < 10; x++) {
- List<Runnable> consumerList = new ArrayList<>();
- for (int i = 0; i < 10; i++) {
- consumerList.add(() -> {});
- }
+ Class<MetricUtils> redefinedMetricUtilsClass =
redefineAsNewClass(MetricUtils.class);
final long usedMetaspaceAfterAllocation = used.getValue();
if (usedMetaspaceInitially != usedMetaspaceAfterAllocation) {
return;
}
+
+ // This assertion try to prevent local variable from gc in absent
of
+ // Reference.reachabilityFence.
+ Assert.assertNotSame(MetricUtils.class, redefinedMetricUtilsClass);
Review comment:
@XComp Here is what I got before resorting to this almost nop method:
* Nop method
[`Reference.reachabilityFence`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ref/Reference.java#L612)
says that "HotSpot JVM retains the ref and does not GC it before a call to
this method, because the JIT-compilers do not have GC-only safepoints."
*
https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051312.html
> JIT-compilers in HotSpot aggressively prune dead locals [1], but they do
that based on method bytecode analysis [2] (and not on optimized IR).
So, any usage of a local extends its live range, even if that usage is
eliminated in generated code. It means an oop in that local will live
past its last usage in generated code and all safepoints (in generated
code) till last usage (on bytecode level) will enumerate the local it is
held in.
From my understanding, both jit and no-jit code will not collect an object
before its last usage.
I agree with you that, an object level `referencedObjects`(which could clean
up using `@After`) list could meet our requirement without resorting to jvm
mystery. Sounds more appropriate before jdk9's `Reference.reachabilityFence` ?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
