On 24/08/2017 4:59 PM, Thomas Stüfe wrote:
Hi David,
our mails crossed :)
And unfortunately we each added in a different hotspot mailing list. :)
<snip>
PS3: We should replace these annoying exit(0) calls with code
that returns
"JNI_SILENT_EXIT", so the C++ code has a chance to finish.
We should certainly look at getting rid of the exit() calls.
Or at least consistently route them through the exit hook if one exists.
It would also be nice to indicate to the caller in whether we were able
to clean up successfully (or did not do anything important yet) or
whether the process is tainted. For example, to allow him to retry
CreateJavaVM with different options.
I think these simple cases all occur during argument processing before
too much of the VM has been initialized. Even so it would probably take
some effort to try and then allow a second call to JNI_CreateJavaVM to
proceed due to use of static initializers and onLoad hooks.
Depending on the exact context it may be better if the process loading
the VM filters out these problematic flags in the first place. They
really only make sense for CLI invocations.
Cheers,
David
-----
Ideally no VM related flag would be of the "report and terminate"
type, as the termination aspect really belongs in the launcher. I
can imagine a launcher using Dcmds to retrieve "help" strings from
subsystems rather than having actual "help" options processed by the
VM (somewhat similar t how -version is handled: create VM, extract
version info, detach VM. exit launcher). That said it would be
somewhat awkward, for example, if the launcher processed -Xlog:help,
but the VM processed all other -Xlog arguments.
This would be a pretty cool feature. It would be nice though if help
could be retrieved without creating the VM first.
..Thomas
Cheers,
David
Best Regards
Adam Farley
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales
with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire PO6 3AU
