How should I stop the forked VM?
Behrooz Nobakht
nobeh5 at gmail.com
Tue Jan 13 13:01:33 UTC 2015
Correction: I'd forgotten to configure the main class for the manifest.
Everything works fine. Thanks.
On Tue, Jan 13, 2015 at 1:04 PM, Behrooz Nobakht <nobeh5 at gmail.com> wrote:
> Hi again,
>
> Not really sure if this now related to this contextual issue or not. I
> updated the example on the GitHub repo. With the way that I run the
> benchmark through run.sh, I get no result file. What am I missing here?!
>
> Thanks,
> Behrooz
>
>
> On Tue, Jan 13, 2015 at 11:19 AM, Behrooz Nobakht <nobeh5 at gmail.com>
> wrote:
>
>> Hi Aleksey,
>>
>> This is much appreciated. I confirm that it works with your changeset.
>>
>> Thanks,
>> Behrooz
>>
>>
>> On Tue, Jan 13, 2015 at 10:38 AM, Aleksey Shipilev <
>> aleksey.shipilev at oracle.com> wrote:
>>
>>> Hi Behrooz,
>>>
>>> On 01/13/2015 11:20 AM, Behrooz Nobakht wrote:
>>> > Thanks for your reply. Hope this helps:
>>> > https://github.com/nobeh/jmh-forked-main-threads
>>>
>>> Thanks for the repoducer!
>>>
>>> I still believe this is a library bug to have stray non-daemon threads
>>> floating around like that. That means any user would have to use
>>> System.exit() to terminate the application, which is smelly smelly smell
>>> that smells a lot.
>>>
>>> Nevertheless, JMH can do a little better:
>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901244
>>> http://hg.openjdk.java.net/code-tools/jmh/rev/d15ebde32b25
>>>
>>> It will now wait for the forked VM to exit properly on its own, and
>>> forcefully terminate the VM if the shutdown timeout is reached. The
>>> timeout is now at 30 seconds. If you want to have a better turnaround
>>> for these benchmarks, submit the upstream bug and demand the library to
>>> stop using the non-daemon threads.
>>>
>>> Thanks,
>>> -Aleksey.
>>>
>>>
>>
>>
>> --
>> -- Behrooz Nobakht
>>
>
>
>
> --
> -- Behrooz Nobakht
>
--
-- Behrooz Nobakht
More information about the jmh-dev
mailing list