Guys, you are right, I was fast and stupid, partially due to personal
time limit.
Still this inspired such an interesting discussion ;)
Really we have a lot of duplication in low-level platform code in
DRLVM, this may become onerous soon enough. BTW, are we interested in
supporting Windows on x86_64? It is listed on [1] but seems nobody
really tests.
[1] http://wiki.apache.org/harmony/Platforms_to_Run_Harmony_Development_Kit_on
2006/11/29, Evgueni Brevnov <[EMAIL PROTECTED]>:
On 11/28/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> Geir Magnusson Jr. wrote:
>
> > Gregory Shimansky wrote:
> >> Gregory Shimansky wrote:
> >>>>> 2) It dropped support for "vm.assert_dialog" switch completely, which
> >>>>> is proved to be quite useful for various kinds of automated testing.
> >>>>> We even discussed recently that launcher lacks similar feature, and I
> >>>>> anticipate other developers will raise complains soon.
> >>>>
> >>>> Despite the fact that "vm.assert_dialog" check was removed, the support
> >>>> is still there: "vm.assert_dialog" controls the behaviour of the
> >>>> default
> >>>> handler.
> >>>>
> >>>> However, you are right that now the overall behaviour is determined
> >>>> by the launcher, so we need to change launcher correspondingly.
> >>>
> >>> Shall we agree that launcher should parse and handle this property?
> >>> The name doesn't look very good to me (Geir will surely ask to change
> >>> it).
> >>>
> >>> What about vm.windows.crt.debug.dialog ? AFAIK the property has no
> >>> effect on linux, and the word "assert" doesn't reflect the purpose of
> >>> this property too.
> >>
> >> Now that I thought about it some more, what about controlling the
> >> launcher default crash handler on all platforms? Specifying something
> >> like -Dhy.launcher.crash.handler=false to disable crash handler
> >> installation in launcher.
> >
> > I like it, except for the preceeding "hy"... also, will this be used by
> > any part of the system other than the launcher?
>
> I don't think it will be used anywhere except for the launcher. It is
> launcher specific and actually Harmony launcher specific.
On Windows except crash handler you need to change the default
behaviour of _CrtDbgReport so it doesn't popup debug window. Currently
it's the VM how changes this behaviour. Do you propose to move this
functionality into launcher as well?
I think VM needs to be able to handle this even w/o the shared launcher.
Just a side note: grepped drlvm, there are 3(!) identical code
snippets for the same:
if (!vm_get_boolean_property_value_with_default("vm.assert_dialog"))
{
disable_assert_dialogs();
}
vm/vmcore/src/init/vm_init.cpp:692
vm/interpreter/src/interp_exports.cpp:132
vm/jitrino/src/vm/drl/DrlJITInterface.cpp:92
:)
>
> Anyway, if you don't mind, I'll try to change the launcher code to use
> "launcher.enable.crash.handler" which should be true by default.
How about using -X<option> instead of -D<option>?
I'm going to integrated HARMONY-1925 soon, which introduces
distinction between Java and VM properties as discussed earlier. Then
it should become -XD<option> :)
Regarding the name, why "launcher" prefix? It may be used by VM as
well, as I said above.
--
Alexey
Evgueni
>
> --
> Gregory
>
>
