[1 of 2] Fix & re-enable perf profiler test: update Java test program to better match test expectations.

[etep]

Summary: In preparation for re-enabling the profiler test cases, we update the Java test program such that its leaf functions do the exact amount of work expected. Previously, we computed two different Fibonacci numbers F27 and F52 with the expectation that F52 would require 2x the work. Unfortunately, there was some variance between JVMs and test runs, and this caused test flakiness.

In this patch, we simplify the test program. The new (and renamed) leaf functions simply count by some increment. The increment is chosen such that a certain leaf function does twice the counting and hence twice the work.

In a future diff, to reduce test run time, we can remove some of the Java test cases in a different PR.

Relevant Issues: #719

Type of change: /kind bug fix.

Test Plan: Tested locally using --runs_per_test=32. All tests passed. Also verified test flakiness by running tests without the fix.

[ddelnano]

We need to remove the DISABLED_ prefix and this TODO, right? Can you confirm that your testing was performed with this applied?

[etep]

Testing was done using a different branch that re-based the next diff (which removes DISABLED_) onto this diff.

[etep]

Converting to draft while the tests run.

[JamesMBartlett]

Is there a reason we can't just sleep for 5 seconds in one and 10 seconds in the other?

[etep]

Does sleep just de-schedule the process? If so, then we probably wouldn't actually see our process doing much at all. Also, this gives us control over the symbols (i.e. versus whatever specific impl. of sleep comes with the multitude of JVMs that we may test with).

[JamesMBartlett]

I suppose sleep wouldn't quite work but something like:

long startTime = System.currentTimeMillis();

while ((System.curentTimeMillis() - startTime) < 5*1000) {
}

seems a lot simpler to me. As it is there's m, n, s, i, j, and k and its quite hard to understand what's going on.

In terms of the stack traces, couldn't we just ignore anything below leaf1x or leaf2x in the stack when doing assertions.

[etep]

We removed some of the seemingly useless code and added a better comment to explain what remains.

In more detail, we ran a few tests to evaluate different versions of ProfilerTest.java.

1. we tested using the call to System.currentTimeMillis().
2. we tested both with and without the "dead" and "useless" code in the loop.

For experiment (1) we found that use of the system call caused stack traces to get "broken": when the stack trace is sampled inside of the clock system call, it does not get connected to its caller, i.e. the system call to clock is not connected to its calling function leaf1x or leaf2x. The test expectations were met, but with fewer samples and more variance.

For experiment (2), we removed the "prime number mod" in the loop. We found that some JVMs were able to statically analyze the very simple code and create a highly optimized representation of the function. For example, without the "dead code" in the loop, for our "azul-zulu-alipine" image, we found that leaf1x and leaf2x did the same amount of work and that they had a 10x speedup versus their "harder to optimize version" that we are merging in this PR. We want the "harder to optimize" version because we want leaf2x and leaf1x to do the work so that our test expectation is met.

[JamesMBartlett]

Seems like a legitimate issue that stack traces are broken on Java with anything that has system calls. I also don't think its a rare case, so likely many users are seeing missing stacktraces (for the functions they care about) when there are system calls involved. But for now I think this is fine to get the test working again.