Compilation warnings and a perf question

[Dmitry Vyazelenko]

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Monday, June 21st, 2021 at 7:55 PM, Aleksey Shipilev <shade at redhat.com> wrote:

> Hi,
>
> On 6/21/21 4:02 PM, Dmitry Vyazelenko wrote:
>
> > -   Warnings when generating and compiling code.
> >
> >     -   The annotation processor:
> >
> >         warning: No processor claimed any of these annotations: org.openjdk.jcstress.annotations.Actor,org.openjdk.jcstress.annotations.Arbiter,org.openjdk.jcstress.annotations.Outcome,org.openjdk.jcstress.annotations.Outcome.Outcomes,org.openjdk.jcstress.annotations.State
> >
> >
> >     -   Generated code:
> >
> >         warning: [rawtypes] found raw type: CounterThread
> >               for (CounterThread t : threads) {
> >                    ^
> >         missing type arguments for generic class CounterThread<R>
> >         where R is a type-variable:
> >           R extends Object declared in class CounterThread
> >
> >
> >     Both could be silenced with `-Xlint:-processing,-rawtypes`.
>
> How exactly did you reproduce this?
>
> I understand the issues, but would like to get builds to fail automatically.

I'm running my build with `-Xlint:all`. The problems described here are in the generated code or reported while such code is generated.
The build is using Gradle. Here is a simplified version of the build file:
```
plugins {
    id 'java-library'
    id 'com.github.johnrengelman.shadow' version '7.0.0'
}

def jcstressVersion='0.13'

repositories {
    mavenCentral()
}

dependencies {
    implementation "org.openjdk.jcstress:jcstress-core:${jcstressVersion}"
    annotationProcessor "org.openjdk.jcstress:jcstress-core:${jcstressVersion}"
}

compileJava {
    options.compilerArgs.add('-Xlint:all')
}

shadowJar {
    archiveFileName = 'jcstress-tests.jar'
    manifest.attributes('Main-Class': 'org.openjdk.jcstress.Main')
}

jar.finalizedBy shadowJar
```

>
> > -   Generation of the HTML report takes forever when a test has lots of unique outcomes and a wildcard matcher is used.
> >
> >     The following test takes 6 minutes to complete when the test is executed without special command line options.
> >
> >     import java.util.concurrent.atomic.AtomicLong;
> >
> >     @JCStressTest
> >     @Outcome(id = ".*, true", expect = Expect.ACCEPTABLE, desc = "Boring")
> >     @State
> >     public class WildcardResultsTest
> >
>
> ...
>
> > Attached is the CPU profile taken with an async-profiler. As can be seen from the profile 96% of time is taken by the `org.openjdk.jcstress.infra.grading.HTMLReportPrinter#emitTestReport` method.
>
> This pain is instructional: you have way too many results on record, because the test initializes
>
> AtomicLong to System.currentTimeMillis() and records current value of AtomicLong into the result!
>
> You probably want to write it as:
>
> @JCStressTest
>
> @Outcome(id = "true", expect = Expect.ACCEPTABLE, desc = "Boring")
>
> @State
>
> public class WildcardResultsTest {
>
> private final AtomicLong counter = new AtomicLong(System.currentTimeMillis());
>
> long c1, c2;
>
> @Actor
>
> public void actor1() {
>
> c1 = counter.getAndIncrement();
>
> }
>
> @Actor
>
> public void actor2() {
>
> c2 = counter.getAndIncrement();
>
> }
>
> @Arbiter
>
> public void arbiter(Z_Result result) {
>
> result.r1 = (c1 != c2);
>
> }
>
> }
>
> I am actually surprised only the HTML report printer is lagging. It lags for several reasons: the
>
> test grading is not cached, so it matches the regexp multiple times over all results; and HTML
>
> report builds a huge table that merges the results from many invocations. That HTML table is 42M long!
>
> It can be helped a bit:
>
> https://github.com/openjdk/jcstress/pull/86
>
> ...but really the test needs fixing.
>
>
I've created this test to illustrate the issue. Thanks for the tip, I've fixed the original test to not generate so many results.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Thanks,
>
> -Aleksey