Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.70 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <44DA12CE.902@pobox.com>
Date: Wed, 09 Aug 2006 12:52:30 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [general] platform support
References: <8E389A5F2FEABA4CB1DEC35A25CB39CE24CF45@mssmsx411>
	 <51d555c70608081840g7c038f51t707775b31fde967e@mail.gmail.com>
	 <44D97D50.1080606@pobox.com>
	 <51d555c70608082345k1c0d0e58y12cb9cf4ad29aa6b@mail.gmail.com>
	 <44D9A4C7.1010607@gmail.com>
 <44D9DF98.1010501@pobox.com>	 <44D9EE95.2040803@gmail.com>
 <26c14c2a0608090841h792bbb54nb76baa40f54b9509@mail.gmail.com>
In-Reply-To: <26c14c2a0608090841h792bbb54nb76baa40f54b9509@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


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