Gotchas with avoiding benchmarks.jar

[Aleksey Shipilev]

So recorded:
 https://bugs.openjdk.java.net/browse/CODETOOLS-7901013

-Aleksey.

On 08/27/2014 08:16 PM, Brian Harris wrote:
> If you like the idea of jmh detecting and aborting concurrent execution,
> consider introducing a file system lock such as
> this https://gist.github.com/brianfromoregon/707ce3a94e45c933f126
> 
> On Wed, Aug 27, 2014 at 5:49 AM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
> 
>     On 08/25/2014 10:08 PM, Brian Harris wrote:
>     > a) looking at handling of jvm args in Runner the safe thing for me
>     is to
>     > always explicitly set OptionsBuilder#jvmArgs (perhaps to an empty set,
>     > even) so that the host JVM args aren't automatically used
> 
>     Yes, that works.
> 
>     > b) junit allows concurrent execution with custom @RunWith but by
>     default
>     > it's always single threaded, so good point tho out of the box behavior
>     > is safe. to be extra sure, Runner (or our wrapper) could acquire a
>     > static lock
> 
>     Static lock does not guard from multiple concurrent JVMs, and many
>     @JUnit test runners I know of are "isolating" the concurrently running
>     tests by forking the VMs.
> 
>     > c) if jmh always generates these two files, Runner could assert
>     they are
>     > present to prevent this case.
> 
>     Oh yes, we need to assert these things.
> 
>     -Aleksey.
> 
>