harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elford, Chris L" <chris.l.elf...@intel.com>
Subject RE: [general] platform support
Date Fri, 11 Aug 2006 18:13:18 GMT
Any _primary_ platform that will be supported by Harmony will probably
need to be put thru a pretty full test protocol on that platform
independent of whether it uses the same binary or a different binary.  I
doubt that the Harmony community will want to target all possible OS
combinations initially.  I think that we should have a serious
discussion on this list about the OS combinations for which we have
"volunteers on board" for "Harmony 1.0".

I don't believe that Harmony should achieve ubiquity by using least
common denominator interfaces.  For x86 32bit-mode systems, I do think
we'll probably need to limit ourselves to one or two binaries.

See http://java.sun.com/j2se/1.5.0/system-configurations.html and
http://edocs.bea.com/jrockit/jrdocs/suppPlat/supp_50.html a list of what
combinations Sun and BEA support today with their Java5 solutions.

I am unconvinced that a combined binary will make testing any easier.  I
believe that the makefile (oops, I mean ant) structure will be easier
with a combined binary but the startup code and some platform specific
optimization code will be more complex as it will need a pretty
sophisticated platform determination and a somewhat manual library
loading process.  At the same time, I believe a combined binary that
includes multipath checks will simplify distribution.  I also believe
that something similar will be necessary for Linuxes though perhaps not
as sophisticated.

Lets say that we decide to go for "complete", "optimal", windows
support.  We would have special case code that chooses appropriate
library interfaces at startup for somewhere between 7 and 18 different
versions of x86 windows, not accounting for service packs:
* x86 Vista home, pro, tablet
* x86 Vista/Longhorn server, webserver
* x86 Vista/longhorn enterprise
* x86 XP home, pro, tablet, media
* x86 XP/2003 server, webserver, Enterprise, Datacenter
* x86 W2K 
* x86 W2K Server, W2K Advanced Server, Datacenter

This of course doesn't account for the either EM64T or Itanium family
processor based systems.  Maybe someone needs to take each OS platform
and list what special interfaces are useful for each one.  I'm
particularly partial to some of the interfaces available only on the
server versions such as the large page APIs:
http://windowssdk.msdn.microsoft.com/en-us/library/ms694004.aspx.

http://windowssdk.msdn.microsoft.com/en-us/library/ms724833.aspx talks
about how to distinguish the different versions and service packs from
each other.  This is probably pretty useful information to report back
to JIRA in the case of a VM crash if we have a single binary release
model.  Of course if one wants to be able to run on windowsMe or
Windows98, one can't rely on these interfaces...  But then since these
aren't actively supported by Microsoft anymore, its unclear how relevant
those platforms are.  

Thanks,

Chris Elford
Intel Middleware Products Division

-----Original Message-----
From: Rana Dasgupta [mailto:rdasgupt@gmail.com] 
Sent: Thursday, August 10, 2006 10:51 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [general] platform support

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

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