You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/08/09 11:03:03 UTC
[general] platform support (was: Re: [general] new snapshots up early
morning... is the win2k problem gone?)
Maybe I'm missing something here, but we 'support' what ever code we
have in our SVN. If somebody wants to work on the code to make it good
for W2K, or Win95, or WinCE ... then why not? Would we really say 'no'?
I agree that we may have more than one binary snapshot/release for
different Windows versions -- but it is one code base, one
configure/make build, etc.
So the question is: should we aim to have a single binary that works on
W2K PIII /and/ WinXP IPF ?
Regards,
Tim
Rana Dasgupta wrote:
> Geir,
> Certainly we can support w2k if we choose to. But I think that the right
> way to do this is to implement, build and test for W2K, not by disabling
> code that will not run on it by trying to support a single binary image
> across OS's. The DRLVM code has not been tested on w2k. It may not be a
> good
> idea to try to achieve this by commenting out the code piece by piece as we
> hit bugs. Are we choosing build on and support W2K as a platform of choice
> for Harmony? If we don't want to do this and just want to somehow enable
> one
> user, we should at least consider branching this code.
> I did not understand your comment about compile time/run time.
> _WIN32_WINNT is the standard way to distinguish between Windows platforms
> and is used everywhere to check platform capability. Are you proposing that
> we should make dynamic runtime os version checks? I am not sure what is the
> benefit of that.
> Regarding your question about whether if it runs on w2k it will also run
> on xp, I am not sure. Usually windows oS's are binary backward compatible
> till ~ W2K, meaning that a W2K binary should somehow run on forward OS's.
> But that is designed only for legacy support and cannot be used for
> performance etc.
>
>
>
>
>
> On 8/8/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>
>>
>> Rana Dasgupta wrote:
>> > Hi,
>> > We have commented out all the stack trace handling code etc. in the NT
>> > exception handing code in drlvm to get the same binary image to run on
>> an
>> > old OS like W2K. I am sorry, but I disagree with this approach.
>>
>> Why? We wanted to make it so a user could try it out. We discussed the
>> approach, and it was a quick fix. What's the problem?
>>
>> > We cannot
>> > compile sources meant for XP/W2003 and expect the binaries to run on
>> lower
>> > Windows OS's. Now we are hitting problems with the vectored exception
>> > handlers which also don't exist on W2K. We cannot comment these out
>> also!
>>
>> No, but we can re-engineer what we're doing.
>>
>>
>> > As Alexey has pointed out, we need to guard the code with the right
>> > _WIN32_WINT guards. The define is 0x501 on XP and 0x502 on W2003.
>> Unless
>> > someone has objects, I am going to turn all this code back on with the
>> > right
>> > _WINT filters.
>>
>> Defines don't solve the problem because they are compile-time, not
>> runtime.
>>
>> > VEH is a feature in the new Windows code base ( the kernel,
>> > debug etc. are common to both OS's and quite different from W2K ).
>> If we
>> > want to support W2K, we will need to rewrite the relevant excpetion
>> > handling
>> > portions and do a build for W2K seperately.
>>
>> Why? Would the solution for W2k not run on WinXP?
>>
>>
>> > The DRLVM code has not been
>> > tested on W2K. There could be more problems. Worse, the code will
>> resolve
>> > the symbols, but behave differently.
>>
>> Right, and the point of making things work for the W2k user is to let
>> that person help test.
>>
>> > A part of the problem is that we haven't defined the minimum machine
>> model
>> > where we want our code to be supported. I would propose that for
>> > x86-W32, we
>> > define it as Intel Pentium IV and WinXP and Windows Server 2003.
>>
>> And why not 2k?
>>
>> > This would
>> > allow us to get away from all these lower level kernel support and also
>> > allow us to avoid doing a lot of unnecessary JIT floating point
>> work. If
>> we
>> > want to support W2K and older machines Pentium III, we will need to
>> make
>> > all
>> > the code changes needed for it and also test it on the down level
>> machines.
>> >
>> > Thanks,
>> > Rana
>> >
>> >
>> >
>> > On 8/7/06, Ivanov, Alexey A <al...@intel.com> wrote:
>> >>
>> >>
>> >> >-----Original Message-----
>> >> >From: Paulex Yang [mailto:paulex.yang@gmail.com]
>> >> >Sent: Monday, August 07, 2006 7:57 AM
>> >> >To: harmony-dev@incubator.apache.org
>> >> >Subject: Re: [general] new snapshots up early morning... is the win2k
>> >> >problem gone?
>> >> >
>> >> >Sorry for response so late, I must get to office for a win2k PC...
>> >> >
>> >> >Just tried it, the dgbhelp.dll error gone, but another one emerge:
>> >> >
>> >> >"Cannot locate entry AddVectoredExceptionHandler at kernel32.dll"
>> >> >(translate from Chinese so probably you'll get a slightly different
>> >> >message from this)
>> >>
>> >> AFAIK this feature (vectored exceptions) is available in Windows XP
>> >> only.
>> >> So it seems we need separate build for Win2K.
>> >>
>> >> Regards,
>> >> Alexey.
>> >>
>> >> >
>> >> >Env:
>> >> >win2k+sp4
>> >> >.net framework 1.1
>> >> >Windows PlatformSDK for Win2003
>> >> >
>> >> >Geir Magnusson Jr wrote:
>> >> >> can anyone test?
>> >> >>
>> >> >> geir
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> >> To unsubscribe, e-mail:
>> harmony-dev-unsubscribe@incubator.apache.org
>> >> >> For additional commands, e-mail:
>> >> harmony-dev-help@incubator.apache.org
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >--
>> >> >Paulex Yang
>> >> >China Software Development Lab
>> >> >IBM
>> >> >
>> >> >
>> >> >
>> >> >---------------------------------------------------------------------
>> >> >Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> >To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> >For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> >>
>> >> --
>> >> Alexey A. Ivanov
>> >> Intel Middleware Product Division
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe'
- missing entry point in KERNEL.dll)
Posted by Paulex Yang <pa...@gmail.com>.
Geir Magnusson Jr wrote:
> I'll add something on the site today, and put notes in the JRE.
>
Great, that will be very helpful.
> I'll also add language to point win2k users to the IBM JRE, but we won't
> publish a snapshot using it - we not only don't have the rights, I think
> it's safe to say that we don't want to.
>
Adding some words is fine, that's what I meant, sorry if I made confusion.
> I'll remove DRLVM from the HDK to make it an easier drop in though, that
> should help.
>
thank you:).
> geir
>
>
> Paulex Yang wrote:
>
>> Before we get an agreement and solution on this issue, I suggest we add
>> some words on it in FAQ/Readme/website or any well known place, it is
>> much better to let our user know earlier than let them down. And because
>> IBM VME can run on Win2k for now, how about we provide it as a
>> workaround for those who are eager to try Harmony on win2k?
>>
>> Paulex Yang wrote:
>>
>>> Just FYI if you haven't seen it, seems yet another win2k user was
>>> complaining on this.
>>>
>>> Radek Terber (JIRA) wrote:
>>>
>>>> Cannot run 'java.exe' - missing entry point in KERNEL.dll
>>>> ---------------------------------------------------------
>>>>
>>>> Key: HARMONY-1145
>>>> URL: http://issues.apache.org/jira/browse/HARMONY-1145
>>>> Project: Harmony
>>>> Issue Type: Bug
>>>> Components: VM
>>>> Environment: Windows 2000 SP4, Harmony snapshot 2006-08-04
>>>> (both HDK and JRE)
>>>> Reporter: Radek Terber
>>>> Attachments: errmsg.gif
>>>>
>>>> When try start JRE using 'java.exe', windows display message (is
>>>> attached to this bug), which means: 'Entry point of procedure
>>>> AddVectorExceptionHandler not found in dynamic link libryry
>>>> KERNEL32.dll'
>>>>
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe'
- missing entry point in KERNEL.dll)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I'll add something on the site today, and put notes in the JRE.
I'll also add language to point win2k users to the IBM JRE, but we won't
publish a snapshot using it - we not only don't have the rights, I think
it's safe to say that we don't want to.
I'll remove DRLVM from the HDK to make it an easier drop in though, that
should help.
geir
Paulex Yang wrote:
> Before we get an agreement and solution on this issue, I suggest we add
> some words on it in FAQ/Readme/website or any well known place, it is
> much better to let our user know earlier than let them down. And because
> IBM VME can run on Win2k for now, how about we provide it as a
> workaround for those who are eager to try Harmony on win2k?
>
> Paulex Yang wrote:
>> Just FYI if you haven't seen it, seems yet another win2k user was
>> complaining on this.
>>
>> Radek Terber (JIRA) wrote:
>>> Cannot run 'java.exe' - missing entry point in KERNEL.dll
>>> ---------------------------------------------------------
>>>
>>> Key: HARMONY-1145
>>> URL: http://issues.apache.org/jira/browse/HARMONY-1145
>>> Project: Harmony
>>> Issue Type: Bug
>>> Components: VM
>>> Environment: Windows 2000 SP4, Harmony snapshot 2006-08-04
>>> (both HDK and JRE)
>>> Reporter: Radek Terber
>>> Attachments: errmsg.gif
>>>
>>> When try start JRE using 'java.exe', windows display message (is
>>> attached to this bug), which means: 'Entry point of procedure
>>> AddVectorExceptionHandler not found in dynamic link libryry
>>> KERNEL32.dll'
>>>
>>>
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe'
- missing entry point in KERNEL.dll)
Posted by Paulex Yang <pa...@gmail.com>.
Before we get an agreement and solution on this issue, I suggest we add
some words on it in FAQ/Readme/website or any well known place, it is
much better to let our user know earlier than let them down. And because
IBM VME can run on Win2k for now, how about we provide it as a
workaround for those who are eager to try Harmony on win2k?
Paulex Yang wrote:
> Just FYI if you haven't seen it, seems yet another win2k user was
> complaining on this.
>
> Radek Terber (JIRA) wrote:
>> Cannot run 'java.exe' - missing entry point in KERNEL.dll
>> ---------------------------------------------------------
>>
>> Key: HARMONY-1145
>> URL: http://issues.apache.org/jira/browse/HARMONY-1145
>> Project: Harmony
>> Issue Type: Bug
>> Components: VM
>> Environment: Windows 2000 SP4, Harmony snapshot 2006-08-04
>> (both HDK and JRE)
>> Reporter: Radek Terber
>> Attachments: errmsg.gif
>>
>> When try start JRE using 'java.exe', windows display message (is
>> attached to this bug), which means: 'Entry point of procedure
>> AddVectorExceptionHandler not found in dynamic link libryry
>> KERNEL32.dll'
>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe'
- missing entry point in KERNEL.dll)
Posted by Paulex Yang <pa...@gmail.com>.
Just FYI if you haven't seen it, seems yet another win2k user was
complaining on this.
Radek Terber (JIRA) wrote:
> Cannot run 'java.exe' - missing entry point in KERNEL.dll
> ---------------------------------------------------------
>
> Key: HARMONY-1145
> URL: http://issues.apache.org/jira/browse/HARMONY-1145
> Project: Harmony
> Issue Type: Bug
> Components: VM
> Environment: Windows 2000 SP4, Harmony snapshot 2006-08-04 (both HDK and JRE)
> Reporter: Radek Terber
> Attachments: errmsg.gif
>
> When try start JRE using 'java.exe', windows display message (is attached to this bug), which means: 'Entry point of procedure AddVectorExceptionHandler not found in dynamic link libryry KERNEL32.dll'
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Rana Dasgupta <rd...@gmail.com>.
Tim,
Thanks for fixing my quoting. I seem to always mess this up :-)
Please see below for a couple of points...
On 8/9/06, Tim Ellison <t....@gmail.com> wrote:
>
> >But there are degrees to which this is done too right? Somewhere along
> >the spectrum from a start-up check that chooses between the winxp.dll
> >and win2k.dll, to repeatedly choosing between any number of possible OS
> >function calls.
Yes, my understanding is that though we choose at startup, we will need to
check the flag before many api/functionality invocations.
>Oh, and I'm assuming that we are leaving the jitted code out of this.
> >Of course the jit will know what platform it is targeting and can
> >generate the code appropriately. So we are discussing the performance
> >
>
>of the interpreter and the compiler itself.
Right Tim and the GC and the thread manager, etc. etc. Jitted code should be
fine.
> The second option is to use a least common denominator approach where
> > we use code/functionality that is only available on the least
> > platform. This is not a good idea for obvious reasons. For example it
> > is not a good idea not to use the excellent vectored exception
> > handling on WinXP and Win2003( which intentionally share the same
> > debug and kernel codebases )If this were not, we would be writing
> > code for DOS only.
>
> >Again, there may be cases where you may well choose the least common
> >denominator solution because it is 'good enough' and the overhead
> >elsewhere (testing etc.) is not worth the gain found here.
>
> >Is vectored exception handling a slam dunk case for making the binary
> >winxp only? I don't know -- what would happen if we didn't use it?
> >Where is the example in the current code that makes ensuring it runs on
> >W2K unpalatable?
I have tried to answer some of these in a seperate reply as best as I know.
>Agree, so there is a balance to be struck. But I'm guessing from you
> >descriptions that you favour this approach of multiple distributions for
> >different OS releases.
>
> Yes, I would certainly favor this :-)
Best,
Rana
Re: [general] platform support
Posted by Tim Ellison <t....@gmail.com>.
(Your post had weird quoting, I've tried to fix it up in my reply)
Rana Dasgupta wrote:
> On 8/9/06, Tim Ellison <t....@gmail.com> wrote:
>> Yes, it is the question you also pose elsewhere -- can we have a binary
>> that either (a) uses the lowest common denominator of the different
>> windows platforms API without incurring an undue penalty performance, or
>> (b) performs runtime checks and picks the best available APIs.
>>
> There are distinct approaches as I understand it.
>
> One option is a single binary image that contains code that supports
> multiple platforms seperately by doing a dynamic check for platform.
> Though less pernicious than a least common denominator approach,
> these runtime checks are not healthy for a binary image that targets
> performance. So if our ideal platform were XinXP, we would incur a
> penalty repeatedly when running with it to accomodate the fact that
> this binary could have also run on W2k.
But there are degrees to which this is done too right? Somewhere along
the spectrum from a start-up check that chooses between the winxp.dll
and win2k.dll, to repeatedly choosing between any number of possible OS
function calls.
Oh, and I'm assuming that we are leaving the jitted code out of this.
Of course the jit will know what platform it is targeting and can
generate the code appropriately. So we are discussing the performance
of the interpreter and the compiler itself.
> The second option is to use a least common denominator approach where
> we use code/functionality that is only available on the least
> platform. This is not a good idea for obvious reasons. For example it
> is not a good idea not to use the excellent vectored exception
> handling on WinXP and Win2003( which intentionally share the same
> debug and kernel codebases )If this were not, we would be writing
> code for DOS only.
Again, there may be cases where you may well choose the least common
denominator solution because it is 'good enough' and the overhead
elsewhere (testing etc.) is not worth the gain found here.
Is vectored exception handling a slam dunk case for making the binary
winxp only? I don't know -- what would happen if we didn't use it?
Where is the example in the current code that makes ensuring it runs on
W2K unpalatable?
> The third is to have a single codebase with the right _WIN32_WINNT
> guards to distinguish platform specific code, and build seperate
> distributions for seperate platforms. This is the most performance
> friendly. It has a building cost, but the major overhead is not
> building, but testing. If we were to support a platform, we would
> need to test on it anyway.
Agree, so there is a balance to be struck. But I'm guessing from you
descriptions that you favour this approach of multiple distributions for
different OS releases.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Oleg Khaschansky <ol...@gmail.com>.
> It has a building
> cost, but the major overhead is not building, but testing. If we were to
> support a platform, we would need to test on it anyway.
Good point! So, "common denominator" approach has at least that
advantage that it needs less testing - on one platform.
On 8/9/06, Rana Dasgupta <rd...@gmail.com> wrote:
> On 8/9/06, Tim Ellison <t....@gmail.com> wrote:
> >
> >
> > >Yes, it is the question you also pose elsewhere -- can we have a binary
> > t>hat either (a) uses the lowest common denominator of the different
> > >windows platforms API without incurring an undue penalty performance, or
> > >(b) performs runtime checks and picks the best available APIs.
> >
> > There are distinct approaches as I understand it.
>
>
> One option is a single binary image that contains code that supports
> > multiple platforms seperately by doing a dynamic check for platform. Though
> > less pernicious than a least common denominator approach, these runtime
> > checks are not healthy for a binary image that targets performance. So if
> > our ideal platform were XinXP, we would incur a penalty repeatedly when
> > running with it to accomodate the fact that this binary could have also run
> > on W2k.
>
>
> The second option is to use a least common denominator approach where we
> use code/functionality that is only available on the least platform. This is
> not a good idea for obvious reasons. For example it is not a good idea not
> to use the excellent vectored exception handling on WinXP and Win2003( which
> intentionally sharethe same debug and kernel codebases )If this were not, we
> would be writing code for DOS only.
>
> The third is to have a single codebase with the right _WIN32_WINNT guards
> to distinguish platform specific code, and build seperate distributions for
> seperate platforms. This is the most performance friendly. It has a building
> cost, but the major overhead is not building, but testing. If we were to
> support a platform, we would need to test on it anyway.
>
> Thanks,
> Rana
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Rana Dasgupta <rd...@gmail.com>.
On 8/9/06, Tim Ellison <t....@gmail.com> wrote:
>
>
> >Yes, it is the question you also pose elsewhere -- can we have a binary
> t>hat either (a) uses the lowest common denominator of the different
> >windows platforms API without incurring an undue penalty performance, or
> >(b) performs runtime checks and picks the best available APIs.
>
> There are distinct approaches as I understand it.
One option is a single binary image that contains code that supports
> multiple platforms seperately by doing a dynamic check for platform. Though
> less pernicious than a least common denominator approach, these runtime
> checks are not healthy for a binary image that targets performance. So if
> our ideal platform were XinXP, we would incur a penalty repeatedly when
> running with it to accomodate the fact that this binary could have also run
> on W2k.
The second option is to use a least common denominator approach where we
use code/functionality that is only available on the least platform. This is
not a good idea for obvious reasons. For example it is not a good idea not
to use the excellent vectored exception handling on WinXP and Win2003( which
intentionally sharethe same debug and kernel codebases )If this were not, we
would be writing code for DOS only.
The third is to have a single codebase with the right _WIN32_WINNT guards
to distinguish platform specific code, and build seperate distributions for
seperate platforms. This is the most performance friendly. It has a building
cost, but the major overhead is not building, but testing. If we were to
support a platform, we would need to test on it anyway.
Thanks,
Rana
Re: [general] platform support
Posted by Chris Gray <ch...@kiffer.be>.
On Wednesday 09 August 2006 17:49, Rana Dasgupta wrote:
> I think Oleg has summarized and expressed better many of the things I was
> trying to say. A single binary on a least common denominator platform is a
> legacy binary. It runs unoptimized on other platforms. Though the term Win
> precedes these Microsoft operatig systems, that's a brand.
It should really be Lose, right?
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 09 August 2006 20:52 Geir Magnusson Jr wrote:
> So - lets start with this -
>
> what are the aspects of the DRLVM codebase that make it not work on
> Win2k, what are the alternatives, and what are the costs to those
> alternatives?
Ok going technical from here. The vectored exception handling API (as opposed
to older structured exception handling mechanism which exists on w2k) was
used when we tried to implement some simple an invocation API implementation
to have a separate launcher. The typical launcher scenario looks like this:
JavaVM *vm = JNI_CreateJavaVM(...);
JNIEnv *jenv = vm->GetEnv(...);
jclass clss = jenv->FindClass(...LAUNCHER_CLASS_NAME...);
jmethodID mid = jenv->GetStaticMethodID(...LAUNCHER_METHOD_NAME...);
jenv->CallVoidMethod(clss, mid);
or something similar. When trying to establish hardware exceptions handling
for hardware NPEs, AEs, SOEs, etc it is necessary to set up a handler for
them right in the call to JNI_CreateJavaVM or GetEnv because all subsequent
calls may execute Java code which may cause the exception.
It is similar to establishing a signal handler for the process, on Linux there
are no problems with signals, but windows implements signals POSIX API in an
ugly unusable way.
The SEH syntax allows to guard a block of code by __try{} __catch{} (MS C++
syntax exgension) syntax and catch hardware exceptions inside of __catch. But
this has a limitation that handling works only on the guarded block. In the
above code example using SEH would require to guard every JNI call by SEH
block to catch hardware exception in any function which may potentially
execute Java code. And if we want a crash handler it is better to guard
blocks which execute *any* code. SEH syntax doesn't allow to do this since
launcher is generally a user code which uses invocation API.
So VEH was really a solution when we found it. I don't really know about
alternatives for w2k. Not that I know much about windows API but we did some
research to find VEH and I don't remember finding any alternatives except for
signals (see above).
There may be of course undocumented API functions (Microsoft is known for this
kind of stuff) which other Java implementations use. There may be also a
possible way of hacking TLS directly since SEH handlers reside on fs:[0]
address, but this may also interfere with C++ handlers from the launcher
because they are implemented through this address as well and if the calling
process uses C++ exceptions (e.g. a web browser) we may crash it.
Do any windows gurus know a solution for w2k?
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Rana Dasgupta <rd...@gmail.com>.
On 8/9/06, Oleg Khaschansky <ol...@gmail.com> wrote:
>
> >Having different codebases is far worse, this implies separate test
> >suites, increased complexity of the build system and other bad things.
> >It would be better to avoid this if possible.
>
> I think that is a price you have decided to pay if you choose to support a
> platform fully. For a complex piece of platform software like DRLVM, to
> newly test and perf tune this on Win2K is not a small task. It is not the
> same as re-running the smoke tests. That is why we need to be sure of what
> our minimal platform commitment is. If it is W2K, we need by definition to
> test on this. If it is only built, but not fully supported ( run at your own
> risk etc. ) on W2K, the cost is lower.
Re: [general] platform support
Posted by Oleg Khaschansky <ol...@gmail.com>.
> This public document I've found with Google proves that
> "SetUnhandledExceptionFilter" is a real candidate for Win2k and production
> level VM
It says also that VM would wrap all JNI and thread start calls into
__try/__except. This is exactly what Gregory complained about.
On 8/10/06, Mikhail Fursov <mi...@gmail.com> wrote:
> +
> This public document I've found with Google proves that
> "SetUnhandledExceptionFilter" is a real candidate for Win2k and production
> level VM
> http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf
>
>
> On 8/10/06, Mikhail Fursov <mike.fursov@gmail.com > wrote:
> >
> > **Using "SetUnhandledExceptionFilter" API call we can handle hardware NPE
> > for Win2k too.
> > The only problem is debbuging of applications with exception filter
> > installed. AFAIK debugger will catch all of these events.
> >
> >
> > On 8/10/06, Oleg Khaschansky <ol...@gmail.com> wrote:
> > >
> > > > The SWT FAQ mentions that the same issue, and recommends the
> > > > following GDI+ redistributable from Microsoft:
> > >
> > > Good, so GDI+ is not a problem!
> > >
> >
> >
> > --
> > Mikhail Fursov
> >
>
>
>
> --
> Mikhail Fursov
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Mikhail Fursov <mi...@gmail.com>.
+
This public document I've found with Google proves that
"SetUnhandledExceptionFilter" is a real candidate for Win2k and production
level VM
http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf
On 8/10/06, Mikhail Fursov <mike.fursov@gmail.com > wrote:
>
> **Using "SetUnhandledExceptionFilter" API call we can handle hardware NPE
> for Win2k too.
> The only problem is debbuging of applications with exception filter
> installed. AFAIK debugger will catch all of these events.
>
>
> On 8/10/06, Oleg Khaschansky <ol...@gmail.com> wrote:
> >
> > > The SWT FAQ mentions that the same issue, and recommends the
> > > following GDI+ redistributable from Microsoft:
> >
> > Good, so GDI+ is not a problem!
> >
>
>
> --
> Mikhail Fursov
>
--
Mikhail Fursov
Re: [general] platform support
Posted by Rana Dasgupta <rd...@gmail.com>.
Hi Mikhail,
As far as I know, SetUnhandledExceptionFilter was introduced as a
backdoor method in in Win2K SP4 to get around the problem that the SEH
handlers are limited to the frame and not process wide. It does handle
problems like NPE and AV, but as you point out, it works by hijacking the
first and last chance debugger handlers. So, unlike VEH which are fully
functional when debugging, these SetUnhandled...filters are not visible when
debugging. I also believe that they execute in the context of the current
thread, which means that they are not so good to handle stack corruption,
SOE etc. which we are currently using VEH. Since one does not expect them to
be used on the newer Windows boxes, the .Net framework overwrites them
...which means that any process that loads a Microsoft dll that has any
Microsoft managed code in it ( and many do ), is at a risk that the
SetUnhandled.. may or may not work.
I think that SetUnhandled..was a great(probably only ) solution on the
Win2K boxes, but VEH was put in place to solve some of its limitations. The
bottom line is that one needs to experiment with this on several Windows
boxes before we know how good or bad it is. I myself don't have a lot of
experience with it.
Thanks,
Rana
On 8/10/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> >**Using "SetUnhandledExceptionFilter" API call we can handle hardware NPE
> >for Win2k too.
> >The only problem is debbuging of applications with exception filter
> >installed. AFAIK debugger will catch all of these events.
>
>
Re: [general] platform support
Posted by Mikhail Fursov <mi...@gmail.com>.
**Using "SetUnhandledExceptionFilter" API call we can handle hardware NPE
for Win2k too.
The only problem is debbuging of applications with exception filter
installed. AFAIK debugger will catch all of these events.
On 8/10/06, Oleg Khaschansky <ol...@gmail.com> wrote:
>
> > The SWT FAQ mentions that the same issue, and recommends the
> > following GDI+ redistributable from Microsoft:
>
> Good, so GDI+ is not a problem!
>
--
Mikhail Fursov
Re: [general] platform support
Posted by Oleg Khaschansky <ol...@gmail.com>.
> The SWT FAQ mentions that the same issue, and recommends the
> following GDI+ redistributable from Microsoft:
Good, so GDI+ is not a problem!
On 8/9/06, Graeme Johnson <Gr...@ca.ibm.com> wrote:
> "Oleg Khaschansky" <ol...@gmail.com> wrote on 08/09/2006
> 01:25:54 PM:
> > Maybe [1] will give some additional info.
> > It is out of the context of DRLVM discussion, but awt uses GDI+
> > extensively. According to [1] GDI+ is not available on w2k.
> >
> > [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-
> > us/sdkintro/sdkintro/windows_xp.asp
>
> The SWT FAQ mentions that the same issue, and recommends the
> following GDI+ redistributable from Microsoft:
>
> http://www.microsoft.com/downloads/details.aspx?FamilyID=6a63ab9c-df12-4d41-933c-be590feaa05a&DisplayLang=en
>
> A quick look at Microsoft's support site indicates that Windows
> 2000 will be in extended support until 2010, so it'll be around
> for some time yet. So this is worth getting right.
>
> http://support.microsoft.com/lifecycle/?LN=en-us&x=18&y=15&p1=3071
>
> IMO having a single distribution that works across OS versions
> and does the runtime-check to select platform specific code
> automatically would be easier for most users. This approach also
> allows you to tune for performance by detecting and leveraging
> knowledge about the hardware (e.g. SMP vs UP optimizations).
>
> /Graeme
>
> Graeme Johnson
> J9 VM Team, IBM Canada
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Rana Dasgupta <rd...@gmail.com>.
On 8/9/06, Oleg Khaschansky <ol...@gmail.com> wrote:
>
> >Maybe [1] will give some additional info.
> >It is out of the context of DRLVM discussion, but awt uses GDI+
> >extensively. According to [1] GDI+ is not available on w2k.
>
> >[1]
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdkintro>/sdkintro/windows_xp.asp
>
>
> I don't have good answers. The DRLVM release notes say that you need VS
.Net 2003 or VC 7 and higher and the corresponding Platform SDK to compile.
I am not even sure that these run on W2000. The way to start to identify
this would be to try and build the sources on a W2K box with the highest
level of compiler available ( VC 6 or VC 7 ) and the SDK, and see what
breaks in the current code. This also impacts not yet committed code.
Broadly,
1) there are changes in thread/fiber api's. For example, GetProcessId,
GetThreadId, GetProcessHandleCount , RestoreLastError etc. are common,
efficient api's not present on 2000. I am sure that the DRLVM code has
plenty of these. Others could be GetThreadIOPendingFlag, Set/Get
ProcessWorkingSetSizeEx etc. which I don't know if DRLVM uses. There is no
use of fibers in DRLVM code.
2) Exceptions: W2K and below support SEH and not Vectored Exceptions which
DRLVM uses.
3)File system: Get/Set DllDirectory, SetFileShortName, ReOpenFile,
GetSystemWOW64Directory are likely api's that drlvm *AND* pending
submissions use. Not present in 2k
4) Memory and System Info: Use of low fragmentation heaps,
GetNativeSystemInfo, GetLogicalProcessorInformation, GetLargePageMinimum
etc. etc. I don't even think that support for large pages and low frag heap
exists in 2k
5) Debug apis: Some basic changes on how to set debug breaks, remote
debugging and just tin time debugging need to be checked out for both
exising AND pending code. debughelp.dll and SymServ.dll to help with symbol
alignment( we hit this ) is not available on 2k. I don't know if we use the
newer error reporting api's like ReportFault, ERExcludedApplication etc
6) Advapi32.dll is used everyewhere and quite radically changed from W2K
7) Many UI api's that I don't really know
Re: [general] platform support
Posted by Graeme Johnson <Gr...@ca.ibm.com>.
"Oleg Khaschansky" <ol...@gmail.com> wrote on 08/09/2006
01:25:54 PM:
> Maybe [1] will give some additional info.
> It is out of the context of DRLVM discussion, but awt uses GDI+
> extensively. According to [1] GDI+ is not available on w2k.
>
> [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/sdkintro/sdkintro/windows_xp.asp
The SWT FAQ mentions that the same issue, and recommends the
following GDI+ redistributable from Microsoft:
http://www.microsoft.com/downloads/details.aspx?FamilyID=6a63ab9c-df12-4d41-933c-be590feaa05a&DisplayLang=en
A quick look at Microsoft's support site indicates that Windows
2000 will be in extended support until 2010, so it'll be around
for some time yet. So this is worth getting right.
http://support.microsoft.com/lifecycle/?LN=en-us&x=18&y=15&p1=3071
IMO having a single distribution that works across OS versions
and does the runtime-check to select platform specific code
automatically would be easier for most users. This approach also
allows you to tune for performance by detecting and leveraging
knowledge about the hardware (e.g. SMP vs UP optimizations).
/Graeme
Graeme Johnson
J9 VM Team, IBM Canada
Re: [general] platform support
Posted by Oleg Khaschansky <ol...@gmail.com>.
Maybe [1] will give some additional info.
It is out of the context of DRLVM discussion, but awt uses GDI+
extensively. According to [1] GDI+ is not available on w2k.
[1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdkintro/sdkintro/windows_xp.asp
On 8/9/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Oleg Khaschansky wrote:
> >> The right way
> >> to do this would be to have different code bases and different
> >> distributions
> >> for W2K and WinXP.
> >
> > Having different codebases is far worse, this implies separate test
> > suites, increased complexity of the build system and other bad things.
> > It would be better to avoid this if possible.
>
> If you are going ot claim that you support a given platform, you better
> test on that platform. I agree that separate codebases have problematic
> aspects (such as ensuring that bugs are fixed in all codebases for a
> given version).
>
> I'll argue again that will help this conversation is a techincal
> discussion about what in DRLVM is winXP specific, what the alternatives
> are, and what the costs are.
>
> Geir
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Oleg Khaschansky wrote:
>> The right way
>> to do this would be to have different code bases and different
>> distributions
>> for W2K and WinXP.
>
> Having different codebases is far worse, this implies separate test
> suites, increased complexity of the build system and other bad things.
> It would be better to avoid this if possible.
If you are going ot claim that you support a given platform, you better
test on that platform. I agree that separate codebases have problematic
aspects (such as ensuring that bugs are fixed in all codebases for a
given version).
I'll argue again that will help this conversation is a techincal
discussion about what in DRLVM is winXP specific, what the alternatives
are, and what the costs are.
Geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Oleg Khaschansky <ol...@gmail.com>.
> The right way
> to do this would be to have different code bases and different distributions
> for W2K and WinXP.
Having different codebases is far worse, this implies separate test
suites, increased complexity of the build system and other bad things.
It would be better to avoid this if possible.
On 8/9/06, Rana Dasgupta <rd...@gmail.com> wrote:
> I think Oleg has summarized and expressed better many of the things I was
> trying to say. A single binary on a least common denominator platform is a
> legacy binary. It runs unoptimized on other platforms. Though the term Win
> precedes these Microsoft operatig systems, that's a brand. W2K, WinXP etc.
> arecompletely different OS's with lose backward compatibility. The right way
> to do this would be to have different code bases and different distributions
> for W2K and WinXP. This may grow worse with Vista. That is unfortunate, but
> that is how Microsoft OS's are.
>
> Thanks,
> Rana
>
>
> On 8/9/06, Oleg Khaschansky <ol...@gmail.com> wrote:
> >
> > BTW what are the real advantages of having one binary?
> >
> > I'd say that having separate binaries is more flexible solution in
> > general:
> > 1. Don't care about performance degradation due to runtime checks.
> > 2. Easy to port to new platforms by expanding #define's.
> > 3. Possibility to link statically against platform-specific libraries.
> > 4. Easy to code platform-specific calls without additional code for
> > dynamic invocations (calling by name, etc.).
> > 5. Possibility of implementing functionality for one particular
> > platform (e.g., we have something on XP for free and need to do a hard
> > work enabling it on 2K), easy platform specific performance tuning.
> > 6. Usage of platform-specific definitions won't break the build on
> > other platforms.
> >
> > And the cost of having one binary rises with the number of differences
> > in the API used. IMO, the best solution is to switch to the separate
> > binary when the amount of platform-specific code becomes not neglible,
> > say 1% :) Or the workload of this code (is it the right word?) becomes
> > reasonably high, resulting in significant performance degradation due
> > to runtime checks.
> >
> > > >> So the question is: should we aim to have a single binary that works
> > on
> > > >> W2K PIII /and/ WinXP IPF ?
> > Hmm, are PIII and IPF binary compatible? At least, there are a lot of
> > compile-time optimizations specific to IPF, if I am not missing
> > something...
> >
> > thanks,
> > Oleg
> >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Rana Dasgupta <rd...@gmail.com>.
I think Oleg has summarized and expressed better many of the things I was
trying to say. A single binary on a least common denominator platform is a
legacy binary. It runs unoptimized on other platforms. Though the term Win
precedes these Microsoft operatig systems, that's a brand. W2K, WinXP etc.
arecompletely different OS's with lose backward compatibility. The right way
to do this would be to have different code bases and different distributions
for W2K and WinXP. This may grow worse with Vista. That is unfortunate, but
that is how Microsoft OS's are.
Thanks,
Rana
On 8/9/06, Oleg Khaschansky <ol...@gmail.com> wrote:
>
> BTW what are the real advantages of having one binary?
>
> I'd say that having separate binaries is more flexible solution in
> general:
> 1. Don't care about performance degradation due to runtime checks.
> 2. Easy to port to new platforms by expanding #define's.
> 3. Possibility to link statically against platform-specific libraries.
> 4. Easy to code platform-specific calls without additional code for
> dynamic invocations (calling by name, etc.).
> 5. Possibility of implementing functionality for one particular
> platform (e.g., we have something on XP for free and need to do a hard
> work enabling it on 2K), easy platform specific performance tuning.
> 6. Usage of platform-specific definitions won't break the build on
> other platforms.
>
> And the cost of having one binary rises with the number of differences
> in the API used. IMO, the best solution is to switch to the separate
> binary when the amount of platform-specific code becomes not neglible,
> say 1% :) Or the workload of this code (is it the right word?) becomes
> reasonably high, resulting in significant performance degradation due
> to runtime checks.
>
> > >> So the question is: should we aim to have a single binary that works
> on
> > >> W2K PIII /and/ WinXP IPF ?
> Hmm, are PIII and IPF binary compatible? At least, there are a lot of
> compile-time optimizations specific to IPF, if I am not missing
> something...
>
> thanks,
> Oleg
>
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [general] platform support
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Oleg Khaschansky wrote:
> BTW what are the real advantages of having one binary?
>
> I'd say that having separate binaries is more flexible solution in general:
> 1. Don't care about performance degradation due to runtime checks.
> 2. Easy to port to new platforms by expanding #define's.
> 3. Possibility to link statically against platform-specific libraries.
> 4. Easy to code platform-specific calls without additional code for
> dynamic invocations (calling by name, etc.).
> 5. Possibility of implementing functionality for one particular
> platform (e.g., we have something on XP for free and need to do a hard
> work enabling it on 2K), easy platform specific performance tuning.
> 6. Usage of platform-specific definitions won't break the build on
> other platforms.
>
> And the cost of having one binary rises with the number of differences
> in the API used. IMO, the best solution is to switch to the separate
> binary when the amount of platform-specific code becomes not neglible,
> say 1% :) Or the workload of this code (is it the right word?) becomes
> reasonably high, resulting in significant performance degradation due
> to runtime checks.
Right - so the key for me here is figuring out these details. What is
XP specific? Are there alternatives that are more general, and what is
the penalty.
We have project goals of several dimensions at play here - such as broad
platform support, performance and stability.
So - lets start with this -
what are the aspects of the DRLVM codebase that make it not work on
Win2k, what are the alternatives, and what are the costs to those
alternatives?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Tim Ellison <t....@gmail.com>.
Alexey Petrenko wrote:
> One binary for PIII and IPF? Really bad idea!
I know, I was just winding him up ;-)
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Alexey Petrenko <al...@gmail.com>.
2006/8/9, Oleg Khaschansky <ol...@gmail.com>:
> BTW what are the real advantages of having one binary?
>
> I'd say that having separate binaries is more flexible solution in general:
> 1. Don't care about performance degradation due to runtime checks.
> 2. Easy to port to new platforms by expanding #define's.
> 3. Possibility to link statically against platform-specific libraries.
> 4. Easy to code platform-specific calls without additional code for
> dynamic invocations (calling by name, etc.).
> 5. Possibility of implementing functionality for one particular
> platform (e.g., we have something on XP for free and need to do a hard
> work enabling it on 2K), easy platform specific performance tuning.
> 6. Usage of platform-specific definitions won't break the build on
> other platforms.
>
> And the cost of having one binary rises with the number of differences
> in the API used. IMO, the best solution is to switch to the separate
> binary when the amount of platform-specific code becomes not neglible,
> say 1% :) Or the workload of this code (is it the right word?) becomes
> reasonably high, resulting in significant performance degradation due
> to runtime checks.
+1
> > >> So the question is: should we aim to have a single binary that works on
> > >> W2K PIII /and/ WinXP IPF ?
> Hmm, are PIII and IPF binary compatible? At least, there are a lot of
> compile-time optimizations specific to IPF, if I am not missing
> something...
One binary for PIII and IPF? Really bad idea!
SY, Alexey
> On 8/9/06, Tim Ellison <t....@gmail.com> wrote:
> > Geir Magnusson Jr wrote:
> > > Tim Ellison wrote:
> > >> Maybe I'm missing something here, but we 'support' what ever code we
> > >> have in our SVN. If somebody wants to work on the code to make it good
> > >> for W2K, or Win95, or WinCE ... then why not? Would we really say 'no'?
> > >>
> > >> I agree that we may have more than one binary snapshot/release for
> > >> different Windows versions -- but it is one code base, one
> > >> configure/make build, etc.
> > >>
> > >> So the question is: should we aim to have a single binary that works on
> > >> W2K PIII /and/ WinXP IPF ?
> > >
> > > That's a different question, isn't it?
> >
> > Yes, it is the question you also pose elsewhere -- can we have a binary
> > that either (a) uses the lowest common denominator of the different
> > windows platforms API without incurring an undue penalty performance, or
> > (b) performs runtime checks and picks the best available APIs.
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Alexey A. Petrenko
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Oleg Khaschansky <ol...@gmail.com>.
BTW what are the real advantages of having one binary?
I'd say that having separate binaries is more flexible solution in general:
1. Don't care about performance degradation due to runtime checks.
2. Easy to port to new platforms by expanding #define's.
3. Possibility to link statically against platform-specific libraries.
4. Easy to code platform-specific calls without additional code for
dynamic invocations (calling by name, etc.).
5. Possibility of implementing functionality for one particular
platform (e.g., we have something on XP for free and need to do a hard
work enabling it on 2K), easy platform specific performance tuning.
6. Usage of platform-specific definitions won't break the build on
other platforms.
And the cost of having one binary rises with the number of differences
in the API used. IMO, the best solution is to switch to the separate
binary when the amount of platform-specific code becomes not neglible,
say 1% :) Or the workload of this code (is it the right word?) becomes
reasonably high, resulting in significant performance degradation due
to runtime checks.
> >> So the question is: should we aim to have a single binary that works on
> >> W2K PIII /and/ WinXP IPF ?
Hmm, are PIII and IPF binary compatible? At least, there are a lot of
compile-time optimizations specific to IPF, if I am not missing
something...
thanks,
Oleg
On 8/9/06, Tim Ellison <t....@gmail.com> wrote:
> Geir Magnusson Jr wrote:
> > Tim Ellison wrote:
> >> Maybe I'm missing something here, but we 'support' what ever code we
> >> have in our SVN. If somebody wants to work on the code to make it good
> >> for W2K, or Win95, or WinCE ... then why not? Would we really say 'no'?
> >>
> >> I agree that we may have more than one binary snapshot/release for
> >> different Windows versions -- but it is one code base, one
> >> configure/make build, etc.
> >>
> >> So the question is: should we aim to have a single binary that works on
> >> W2K PIII /and/ WinXP IPF ?
> >
> > That's a different question, isn't it?
>
> Yes, it is the question you also pose elsewhere -- can we have a binary
> that either (a) uses the lowest common denominator of the different
> windows platforms API without incurring an undue penalty performance, or
> (b) performs runtime checks and picks the best available APIs.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> Maybe I'm missing something here, but we 'support' what ever code we
>> have in our SVN. If somebody wants to work on the code to make it good
>> for W2K, or Win95, or WinCE ... then why not? Would we really say 'no'?
>>
>> I agree that we may have more than one binary snapshot/release for
>> different Windows versions -- but it is one code base, one
>> configure/make build, etc.
>>
>> So the question is: should we aim to have a single binary that works on
>> W2K PIII /and/ WinXP IPF ?
>
> That's a different question, isn't it?
Yes, it is the question you also pose elsewhere -- can we have a binary
that either (a) uses the lowest common denominator of the different
windows platforms API without incurring an undue penalty performance, or
(b) performs runtime checks and picks the best available APIs.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] platform support
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Maybe I'm missing something here, but we 'support' what ever code we
> have in our SVN. If somebody wants to work on the code to make it good
> for W2K, or Win95, or WinCE ... then why not? Would we really say 'no'?
>
> I agree that we may have more than one binary snapshot/release for
> different Windows versions -- but it is one code base, one
> configure/make build, etc.
>
> So the question is: should we aim to have a single binary that works on
> W2K PIII /and/ WinXP IPF ?
That's a different question, isn't it?
geir
>
> Regards,
> Tim
>
> Rana Dasgupta wrote:
>> Geir,
>> Certainly we can support w2k if we choose to. But I think that the right
>> way to do this is to implement, build and test for W2K, not by disabling
>> code that will not run on it by trying to support a single binary image
>> across OS's. The DRLVM code has not been tested on w2k. It may not be a
>> good
>> idea to try to achieve this by commenting out the code piece by piece as we
>> hit bugs. Are we choosing build on and support W2K as a platform of choice
>> for Harmony? If we don't want to do this and just want to somehow enable
>> one
>> user, we should at least consider branching this code.
>> I did not understand your comment about compile time/run time.
>> _WIN32_WINNT is the standard way to distinguish between Windows platforms
>> and is used everywhere to check platform capability. Are you proposing that
>> we should make dynamic runtime os version checks? I am not sure what is the
>> benefit of that.
>> Regarding your question about whether if it runs on w2k it will also run
>> on xp, I am not sure. Usually windows oS's are binary backward compatible
>> till ~ W2K, meaning that a W2K binary should somehow run on forward OS's.
>> But that is designed only for legacy support and cannot be used for
>> performance etc.
>>
>>
>>
>>
>>
>> On 8/8/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>
>>>
>>> Rana Dasgupta wrote:
>>>> Hi,
>>>> We have commented out all the stack trace handling code etc. in the NT
>>>> exception handing code in drlvm to get the same binary image to run on
>>> an
>>>> old OS like W2K. I am sorry, but I disagree with this approach.
>>> Why? We wanted to make it so a user could try it out. We discussed the
>>> approach, and it was a quick fix. What's the problem?
>>>
>>>> We cannot
>>>> compile sources meant for XP/W2003 and expect the binaries to run on
>>> lower
>>>> Windows OS's. Now we are hitting problems with the vectored exception
>>>> handlers which also don't exist on W2K. We cannot comment these out
>>> also!
>>>
>>> No, but we can re-engineer what we're doing.
>>>
>>>
>>>> As Alexey has pointed out, we need to guard the code with the right
>>>> _WIN32_WINT guards. The define is 0x501 on XP and 0x502 on W2003.
>>> Unless
>>>> someone has objects, I am going to turn all this code back on with the
>>>> right
>>>> _WINT filters.
>>> Defines don't solve the problem because they are compile-time, not
>>> runtime.
>>>
>>>> VEH is a feature in the new Windows code base ( the kernel,
>>>> debug etc. are common to both OS's and quite different from W2K ).
>>> If we
>>>> want to support W2K, we will need to rewrite the relevant excpetion
>>>> handling
>>>> portions and do a build for W2K seperately.
>>> Why? Would the solution for W2k not run on WinXP?
>>>
>>>
>>>> The DRLVM code has not been
>>>> tested on W2K. There could be more problems. Worse, the code will
>>> resolve
>>>> the symbols, but behave differently.
>>> Right, and the point of making things work for the W2k user is to let
>>> that person help test.
>>>
>>>> A part of the problem is that we haven't defined the minimum machine
>>> model
>>>> where we want our code to be supported. I would propose that for
>>>> x86-W32, we
>>>> define it as Intel Pentium IV and WinXP and Windows Server 2003.
>>> And why not 2k?
>>>
>>>> This would
>>>> allow us to get away from all these lower level kernel support and also
>>>> allow us to avoid doing a lot of unnecessary JIT floating point
>>> work. If
>>> we
>>>> want to support W2K and older machines Pentium III, we will need to
>>> make
>>>> all
>>>> the code changes needed for it and also test it on the down level
>>> machines.
>>>> Thanks,
>>>> Rana
>>>>
>>>>
>>>>
>>>> On 8/7/06, Ivanov, Alexey A <al...@intel.com> wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Paulex Yang [mailto:paulex.yang@gmail.com]
>>>>>> Sent: Monday, August 07, 2006 7:57 AM
>>>>>> To: harmony-dev@incubator.apache.org
>>>>>> Subject: Re: [general] new snapshots up early morning... is the win2k
>>>>>> problem gone?
>>>>>>
>>>>>> Sorry for response so late, I must get to office for a win2k PC...
>>>>>>
>>>>>> Just tried it, the dgbhelp.dll error gone, but another one emerge:
>>>>>>
>>>>>> "Cannot locate entry AddVectoredExceptionHandler at kernel32.dll"
>>>>>> (translate from Chinese so probably you'll get a slightly different
>>>>>> message from this)
>>>>> AFAIK this feature (vectored exceptions) is available in Windows XP
>>>>> only.
>>>>> So it seems we need separate build for Win2K.
>>>>>
>>>>> Regards,
>>>>> Alexey.
>>>>>
>>>>>> Env:
>>>>>> win2k+sp4
>>>>>> .net framework 1.1
>>>>>> Windows PlatformSDK for Win2003
>>>>>>
>>>>>> Geir Magnusson Jr wrote:
>>>>>>> can anyone test?
>>>>>>>
>>>>>>> geir
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>>>> To unsubscribe, e-mail:
>>> harmony-dev-unsubscribe@incubator.apache.org
>>>>>>> For additional commands, e-mail:
>>>>> harmony-dev-help@incubator.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Paulex Yang
>>>>>> China Software Development Lab
>>>>>> IBM
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail:
>>> harmony-dev-help@incubator.apache.org
>>>>> --
>>>>> Alexey A. Ivanov
>>>>> Intel Middleware Product Division
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org