Re: [general] platform support
Elford, Chris L wrote: > 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. Yes - the testing for a given platform is independent of the platform. > 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". We are having one. > > 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. Hang on - do you think anyone is advocating ubiquity via LCD interfaces? What we needed was a focused discussion on the technological trade-offs, and I think we're having one. > > 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 think you are focusing on the wrong argument or something. I don't think anyone is seriously suggesting we'd do that for testing purposes, because we have to test on any platform we claim to support. The combined binary will make life easier for users and distributors. This started as a debate over whether or not we will even support win2k, because people were trying to use harmony on it. >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. Right. Exactly. > > 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 Do you think this software will ever be released? :) It would be interesting to see if what we have even runs on Vista > * 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. I think fairly irrelevant, but if someone did step up and wanted to do the work, I wouldn't stand in their way :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
Elford, Chris L wrote: > 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. Yes - the testing for a given platform is independent of the platform. > 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". We are having one. > > 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. Hang on - do you think anyone is advocating ubiquity via LCD interfaces? What we needed was a focused discussion on the technological trade-offs, and I think we're having one. I also think that calling them "LCD" is somewhat of a charged phrase, as it pre-judges the usefulness or appropriateness. For example, using something specific to XP might not be any better but be just some kind of lock-in feature... > > 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 know it was mentioned, but I don't think anyone is seriously suggesting it as a major motivation because we have to test on any platform we claim to support. The combined binary will make life easier for users and distributors. This started as a debate over whether or not we will even support win2k, because people were trying to use harmony on it. >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. Right. Exactly. > > 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 Do you think this software will ever be released? :) It would be interesting to see if what we have runs on Vista now. Anyone have a copy running? > * 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. I think fairly irrelevant, but if someone did step up and wanted to do the work, I wouldn't stand in their way :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe' - missing entry point in KERNEL.dll)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] platform support
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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe' - missing entry point in KERNEL.dll)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe' - missing entry point in KERNEL.dll)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe' - missing entry point in KERNEL.dll)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] platform support
Rana, SetUnhandledExceptionFilter [1] is documented function which is available since Windows 95. It is part of the Structured Exception Handling. Windows XP introduced the Vectored Exception Handling which is an extension of SEH according to MSDN. Using this function and therefore SEH (but not VEH) mechanism requires you to guard each call with __try/__except as Gregory and Oleg pointed out. I'm not proficient in this kind of rather low-level Windows API though, so I might be wrong. Regards, Alexey. [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/b ase/setunhandledexceptionfilter.asp -- Alexey A. Ivanov Intel Middleware Product Division >-Original Message- >From: Rana Dasgupta [mailto:[EMAIL PROTECTED] >Sent: Thursday, August 10, 2006 9:51 PM >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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
+ 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 <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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
**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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> wrote: "Oleg Khaschansky" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] platform support
>-Original Message- >From: Tim Ellison [mailto:[EMAIL PROTECTED] >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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) >IBM Java technology centre, UK. > >- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] platform support
>-Original Message- >From: Oleg Khaschansky [mailto:[EMAIL PROTECTED] >Sent: Wednesday, August 09, 2006 9:26 PM >To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] >Subject: Re: [general] platform support > >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 AFAIK it is available as additional download for Win2K users, moreover for Win9x family as well [2]. Regards, Alexey. [2] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdicpp/ GDIPlus/GDIPlus.asp (in Where Applicable section) > >On 8/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] platform support
>-Original Message- >From: Oleg Khaschansky [mailto:[EMAIL PROTECTED] >Sent: Wednesday, August 09, 2006 8:42 PM >To: harmony-dev@incubator.apache.org >Subject: Re: [general] platform support > >> 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. It needs the same amount of testing because we must ensure the code behaves the same way on all platforms we support. It doesn't depend on whether we use one binary for all platforms, or whether we have different binaries. Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
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 <[EMAIL PROTECTED]> 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
On 8/9/06, Oleg Khaschansky <[EMAIL PROTECTED]> 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
Alexey Petrenko wrote: > One binary for PIII and IPF? Really bad idea! I know, I was just winding him up ;-) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
"Oleg Khaschansky" <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
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, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
On 8/9/06, Oleg Khaschansky <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> wrote: On 8/9/06, Tim Ellison <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
On 8/9/06, Tim Ellison <[EMAIL PROTECTED]> 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
2006/8/9, Oleg Khaschansky <[EMAIL PROTECTED]>: 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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > >> -Original Message- >> From: Paulex Yang [mailto:[EMAIL PROTECTED] >> 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 (vect