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