search

melix / jmh-gradle-plugin

Integrates the JMH benchmarking framework with Gradle
Apache License 2.0
666 stars 88 forks source link

Regenerating Source Files #132

Closed deaddowney closed 3 years ago

deaddowney commented 6 years ago

I am unclear as to how the JMH benchmark tests are generated. If I manually remove a Benchmark annotated method and then run gradle clean jmh

I often get compilation errors, saying that there is no reference to the method I just removed. If I look at the BenchmarkList, I see the old method there. This doesn't happen every time, but it happens often enough. Where is this information cached and how can I be sure that the generated source code is correct based off of my Benchmark methods?

cowtowncoder commented 6 years ago

I am also facing this problem I think: I am essentially getting compilation errors for stale sources (from earlier versions of modified sources). clean does not help. I am using IntelliJ Idea if that matters, for editing, but running gradle from shell.

cowtowncoder commented 6 years ago

Not sure if this helps, but I FINALLY found a work-around for my specific problem:

gradle --no-daemon

which sorta kinda makes sense if the root cause is that plugin retains some information it should not (and/or offers no way to clean it).

Rebuilding is slow, but at least things work. Hope it might help others.

melix commented 6 years ago

What version of the plugin are you using? The plugin doesn't retain any particular state that would explain this.

melix commented 6 years ago

Seems to be a duplicate of #114

cowtowncoder commented 6 years ago

Latest at the time of writing (2.4.7?) -- traveling so can not double-check but it was not an older version. In theory it could also be related to gradle as there's some in-house (at work) fork of gradle for reasons unknown to me, just for my case. But curious since others have reported what seem like similar issues.

FauxFaux commented 6 years ago

I'm definitely still seeing this on 0.4.7. All the time. Exactly the same symptoms / solution as #114.

ilyakharlamov commented 5 years ago

0.4.7, gradle 5.0 - when changing a @Benchmark file in src/jmh folder: gradle clean jmh - doesn't help rm -rf build;gradle clean jmh - doesn't help rm -rf .gradle;gradle clean jmh - doesn't help gradle --no-build-cache clean jmh - doesn't help gradle --no-daemon jmh - doesn't help gradle --no-daemon clean jmh - always helps, works fine

sebersole commented 5 years ago

+1 - bit by this as well.

grv87 commented 5 years ago

See discussion at #145 and gradle/gradle#937

MariusVolkhart commented 3 years ago

We've encountered this when using the Gradle build cache. Killing daemons or restarting them doesn't matter in that case it seems. Specifying --no-build-cache is our current workaround

grv87 commented 3 years ago

Since discussion in gradle/gradle#937 went nowhere I believe the correct current approach is

dynamic jars should have different filenames each time

And, to make builds consistent and build cache usable, this dynamic part of the filename should be sources' hash.

MariusVolkhart commented 3 years ago

It looks like this regression occurred as a result of Use JavaExec for JmhBytecodeGeneratorTask. As was fixed by c957e9f for #114, the JMH generator does not automatically clean-up old sources. This must be done manually. The switch to using JavaExec appears to have missed bringing over the cleanup code.