harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivanov, Alexey A" <alexey.a.iva...@intel.com>
Subject RE: [general] platform support
Date Thu, 10 Aug 2006 07:54:09 GMT
>-----Original Message-----
>From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>Sent: Wednesday, August 09, 2006 10:07 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [general] platform support
>
>(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.p.ellison@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.

I also thought about the approach of using just separate DLLs with the
same external API. At start-up the VM chooses one of them, and then
forgets about platform-specific differences. This might be a rather good
solution.


Regards,
Alexey.


>
>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

--
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


Mime
View raw message