You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nd...@apache.org> on 2007/03/31 05:34:12 UTC
[general] What platforms do we support?
Over the past few months I've been experimenting with various platform
configurations to run the build tests on and I've been running into
enormous hurdles that seem to all be turning out to be undocumented
platform requirements.
Currently, the downloads page [1] separates the available snapshots
into three platforms; Windows 32-bit, Linux 32-bit and Linux 64-bit.
All of these platforms are Intel-based x86, one would have to guess.
The Wiki has a section called "porting matrix" [2], which seems
specific to DRLVM. This seems to indicate that only the latest
platforms are supported; IA32 with SSE/SSE2 (what does that even
mean?) on Linux and WinXP/2003, IA64 and AMD64 on Linux.
What I have found anecdotally is
* Classlib blows chunks on Windows 2000 because of the AWT/Swing code.
* DRLVM blows chunks, hard, on Pentium III and Pentium III Xeon systems
* IBM's VM works on Windows 2000, 2003, XP and on P3+ systems
My point being, this is confusing. At the very least, it's not clearly
documented; does the classlib have different requirements or the same
as DRLVM? DRLVM can't run on P3 chips; isn't that a little silly? How
many P3-based servers are there out there that run J2EE app servers?
Regardless, I think we need to come to a common understanding
(decision), document it and test against it.
-Nathan
[1] http://harmony.apache.org/downloads.html
[2] http://harmony.apache.org/roadmap.html#Porting%20Matrix
Re: [general] What platforms do we support?
Posted by Alexey Petrenko <al...@gmail.com>.
As I said few times today and before... :)
Yes, it looks like we can make uxtheme.dll an optional dependency for
AWT module. I hope that will be enough to support W2K.
And yes, I agree that we need to add this modification to our pre
JavaOne issue list.
I also believe that we definitely need Linux support.
SY, Alexey
2007/4/2, Tim Ellison <t....@gmail.com>:
> Nathan Beyer wrote:
> > However, from looking back on this mailing list thread, I couldn't
> > find any decision at the end of this or much of a consensus. I would
> > like to pull this together, vote on it. document it (site, Wiki, etc),
> > test it, etc.
>
> Agreed, let's try and get a consensus on what we will have in our M1
> build, and a date to shoot for it.
>
> I think we have a reasonable idea forming that it will be (taken from
> your list):
>
> - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> - IA64/IPF (Intel 64-bit architecture)
> - x86_64/AMD64/EMT64 (AMD architecture)
>
> - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> Windows 2003 R2, (Windows Vista?)
> - Linux; kernel v2.4.x, v2.6.x
> - (FreeBSD v???)
>
> I've put some in parentheses since we need to hear from people what work
> is required to get them ready and stable. I also removed the priority
> order since I think they are all equally important if we declare them
> stable.
>
> An M1 date of April 30th would give us a stable build ready for
> ApacheCon EU and JavaOne, which seems like a good goal. Working
> backwards we would then focus on stability for whatever we have got from
> April 23.
>
> I wonder if the Win2000 goal is possible in that timeframe? If not I
> suggest we live with WinXP as a minimum requirement for M1. Do we know
> what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
> work remaining and we should drop it from M1 if so.
>
> Regards,
> Tim
>
Re: [general] What platforms do we support?
Posted by Tim Ellison <t....@gmail.com>.
Rana Dasgupta wrote:
> This sounds like a good idea. I also don't know if anyone is testing
> on Vista. If we want to target April 30, would it make sense to have a
> small set of platforms and focus on stability and reasonably good
> performance ...say x86-32 bit on XP SP2 and W2003 R2 ( where we are
> most stable, but still have threading issues ) and Linux kernel
> version 2.6( only if achievable )? We can always add platforms with
> future releases.
Yes, we should focus on the platforms where stability and reasonable
performance are achievable. I thought that those I mentioned are
achievable by that date, but I'm prepared to be corrected.
Regards,
Tim
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
On 4/2/07, Tim Ellison <t....@gmail.com> wrote:
> Nathan Beyer wrote:
> > However, from looking back on this mailing list thread, I couldn't
> > find any decision at the end of this or much of a consensus. I would
> > like to pull this together, vote on it. document it (site, Wiki, etc),
> > test it, etc.
>
> Agreed, let's try and get a consensus on what we will have in our M1
> build, and a date to shoot for it.
>
> I think we have a reasonable idea forming that it will be (taken from
> your list):
>
> - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> - IA64/IPF (Intel 64-bit architecture)
> - x86_64/AMD64/EMT64 (AMD architecture)
>
> - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> Windows 2003 R2, (Windows Vista?)
> - Linux; kernel v2.4.x, v2.6.x
> - (FreeBSD v???)
>
> I've put some in parentheses since we need to hear from people what work
> is required to get them ready and stable. I also removed the priority
> order since I think they are all equally important if we declare them
> stable.
>
> An M1 date of April 30th would give us a stable build ready for
> ApacheCon EU and JavaOne, which seems like a good goal. Working
> backwards we would then focus on stability for whatever we have got from
> April 23.
>
> I wonder if the Win2000 goal is possible in that timeframe? If not I
> suggest we live with WinXP as a minimum requirement for M1.
This sounds like a good idea. I also don't know if anyone is testing
on Vista. If we want to target April 30, would it make sense to have a
small set of platforms and focus on stability and reasonably good
performance ...say x86-32 bit on XP SP2 and W2003 R2 ( where we are
most stable, but still have threading issues ) and Linux kernel
version 2.6( only if achievable )? We can always add platforms with
future releases.
> Do we know
> what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
> work remaining and we should drop it from M1 if so.
>
> Regards,
> Tim
>
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
On 4/2/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> On 4/3/07, Tim Ellison <t....@gmail.com> wrote:
> >
> > Nathan Beyer wrote:
> > > However, from looking back on this mailing list thread, I couldn't
> > > find any decision at the end of this or much of a consensus. I would
> > > like to pull this together, vote on it. document it (site, Wiki, etc),
> > > test it, etc.
> >
> > Agreed, let's try and get a consensus on what we will have in our M1
> > build, and a date to shoot for it.
> >
> > I think we have a reasonable idea forming that it will be (taken from
> > your list):
> >
> > - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> > - IA64/IPF (Intel 64-bit architecture)
> > - x86_64/AMD64/EMT64 (AMD architecture)
> >
> > - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > Windows 2003 R2, (Windows Vista?)
> > - Linux; kernel v2.4.x, v2.6.x
> > - (FreeBSD v???)
> >
> > I've put some in parentheses since we need to hear from people what work
> > is required to get them ready and stable. I also removed the priority
> > order since I think they are all equally important if we declare them
> > stable.
> >
> > An M1 date of April 30th would give us a stable build ready for
> > ApacheCon EU and JavaOne, which seems like a good goal. Working
> > backwards we would then focus on stability for whatever we have got from
> > April 23.
> >
> > I wonder if the Win2000 goal is possible in that timeframe? If not I
> > suggest we live with WinXP as a minimum requirement for M1. Do we know
> > what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
> > work remaining and we should drop it from M1 if so.
> >
> > Regards,
> > Tim
>
>
>
> I think having a milestone we want to show a really fast and stable runtime
> environment, not just another snapshot of what we have to the moment. If I'm
> correct than 1 week between the feature freeze and release date is not
> enough. Working on JIT I see ~30 JIRA issues that may affect real
> applications, and running recently contributed test suites will reveal
> more. I think we should strive to fix most of them before the milestone,
> probably by the cost of limiting number of supported platforms. Then we may
> go to the next milestone, including more platforms/configurations.
>
>
>
> Having this in mind I propose to release M1 with IA32 support only, may be
> even limiting this support to Windows. Let's fix all stability problems
> there and then go to the next milestone shortly, including support for Linux
> or x86_64. I propose a feature freeze date of 15th of May and put M1 release
> date of 15th of June. At the feature freeze we should complete current
> development works and move on to stability to release a really mature
> runtime. We might have release an "release candidate" before the JavaOne
> which will have all the capabilities than our milestone build but without
> all stability issues fixed.
>
>
>
> I also have comments about configurations:
>
> *- IA32/x86 with a minimum of P3 (SSE, not SSE2)*
> **
> **
>
> SSE+SSE2 unless someone commits to test and complete on pure PIII.
I have a Windows 2000 PIII box running (failing) builds constantly
right now, so testing shouldn't be an issue. It's not surprising that
people hanging out on the list don't have PIII or Windows 2000 boxes,
but we're likely quick-adapter apologists. There is a lot of server
hardware out there that's still running PIII and Windows 2000. Try a
search for used servers on eBay.
I also have a Linux PIII Xeon (Quad) that I can run builds on as well.
-Nathan
> *- IA64/IPF (Intel 64-bit architecture)*
>
> DRLVM is poorly tested on IPF yet. This is rather for M3 milestone.
>
> *- x86_64/AMD64/EMT64 (AMD architecture)*
> Let's put this aside for the first release. We have some stability level
> there which is supported by CruiseControl and no regression on these
> platform is enough for the first release. I'm fine to include this into M1
> if someone commit to this.
>
> *- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> Windows 2003 R2, (Windows Vista?)*
>
>
>
> + 1 for Windows 2003, Windows XP. It's interesting to try on Vista but I'd
> give it some time to "grow up" before we go there.
>
>
> *- Linux; kernel v2.4.x, v2.6.x*
>
>
>
> I'm sure Geir will vote for Linux, but I'm reluctant to put everything in
> the first milestone.
>
>
> *- (FreeBSD v???)
> *
>
> Volunteers? ;-)
>
>
>
> Thank you,
>
> Pavel Ozhdikhin
>
> Intel Managed Runtime Division
>
Re: [general] What platforms do we support?
Posted by Alexey Petrenko <al...@gmail.com>.
2007/4/4, Evgueni Brevnov <ev...@gmail.com>:
> Hi,
>
> Seems like this is not a technical discussion anyway I did some
> expiriments on my Fedora Core release 5 (Bordeaux) PentiumIII
> machine. Additionally to HARMONY-3246 it required a few modifications
> in sources and proper arguments to the compiler to run HelloWord and
> other applications. I can provide a patch with modifications to
> building system to build PentiumIII friendly VM. Is anyone intrested
> in this?
Yes, sure. That would be nice.
And we should check that it does not reflect performance...
SY, Alexey
>
> Evgueni.
>
> On 4/3/07, Mikhail Loenko <ml...@gmail.com> wrote:
> > Fortunately we don't have to follow outcomes of those discussions
> > when we work in Harmony :)
> >
> > Still we can ask the teams you referred to provide their feedback (if possible)
> > to a wider audience
> >
> > As for the platforms some time ago Stepan said (and many people agreed to him)
> > that most of the things that we currently fix are OS-independent, so
> > we can focus
> > on 32-bit architecture and not tie ourselves much to a specific platform
> >
> > Thanks,
> > Mikhail
> >
> > 2007/4/3, Rana Dasgupta <rd...@gmail.com>:
> > > Hi Xiao Feng,
> > > You probably missed this, but we have taken an internal Intel
> > > target to release Harmony first on Win32 in Q2 after a lot of
> > > discussions in Judy's JCM meeting, based primarily on feedback from
> > > the JIT and performance teams.
> > >
> > > Rana
> > >
> > > On 4/2/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > On 4/3/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > > > > On 4/3/07, Tim Ellison <t....@gmail.com> wrote:
> > > > > >
> > > > > > Nathan Beyer wrote:
> > > > > > > However, from looking back on this mailing list thread, I couldn't
> > > > > > > find any decision at the end of this or much of a consensus. I would
> > > > > > > like to pull this together, vote on it. document it (site, Wiki, etc),
> > > > > > > test it, etc.
> > > > > >
> > > > > > Agreed, let's try and get a consensus on what we will have in our M1
> > > > > > build, and a date to shoot for it.
> > > > > >
> > > > > > I think we have a reasonable idea forming that it will be (taken from
> > > > > > your list):
> > > > > >
> > > > > > - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> > > > > > - IA64/IPF (Intel 64-bit architecture)
> > > > > > - x86_64/AMD64/EMT64 (AMD architecture)
> > > > > >
> > > > > > - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > > > > > Windows 2003 R2, (Windows Vista?)
> > > > > > - Linux; kernel v2.4.x, v2.6.x
> > > > > > - (FreeBSD v???)
> > > > > >
> > > > > > I've put some in parentheses since we need to hear from people what work
> > > > > > is required to get them ready and stable. I also removed the priority
> > > > > > order since I think they are all equally important if we declare them
> > > > > > stable.
> > > > > >
> > > > > > An M1 date of April 30th would give us a stable build ready for
> > > > > > ApacheCon EU and JavaOne, which seems like a good goal. Working
> > > > > > backwards we would then focus on stability for whatever we have got from
> > > > > > April 23.
> > > > > >
> > > > > > I wonder if the Win2000 goal is possible in that timeframe? If not I
> > > > > > suggest we live with WinXP as a minimum requirement for M1. Do we know
> > > > > > what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
> > > > > > work remaining and we should drop it from M1 if so.
> > > > > >
> > > > > > Regards,
> > > > > > Tim
> > > > >
> > > > >
> > > > >
> > > > > I think having a milestone we want to show a really fast and stable runtime
> > > > > environment, not just another snapshot of what we have to the moment. If I'm
> > > > > correct than 1 week between the feature freeze and release date is not
> > > > > enough. Working on JIT I see ~30 JIRA issues that may affect real
> > > > > applications, and running recently contributed test suites will reveal
> > > > > more. I think we should strive to fix most of them before the milestone,
> > > > > probably by the cost of limiting number of supported platforms. Then we may
> > > > > go to the next milestone, including more platforms/configurations.
> > > > >
> > > > >
> > > > >
> > > > > Having this in mind I propose to release M1 with IA32 support only, may be
> > > > > even limiting this support to Windows. Let's fix all stability problems
> > > > > there and then go to the next milestone shortly, including support for Linux
> > > > > or x86_64. I propose a feature freeze date of 15th of May and put M1 release
> > > > > date of 15th of June. At the feature freeze we should complete current
> > > > > development works and move on to stability to release a really mature
> > > > > runtime. We might have release an "release candidate" before the JavaOne
> > > > > which will have all the capabilities than our milestone build but without
> > > > > all stability issues fixed.
> > > > >
> > > > >
> > > > >
> > > > > I also have comments about configurations:
> > > > >
> > > > > *- IA32/x86 with a minimum of P3 (SSE, not SSE2)*
> > > > > **
> > > > > **
> > > > >
> > > > > SSE+SSE2 unless someone commits to test and complete on pure PIII.
> > > > > *- IA64/IPF (Intel 64-bit architecture)*
> > > > >
> > > > > DRLVM is poorly tested on IPF yet. This is rather for M3 milestone.
> > > > >
> > > > > *- x86_64/AMD64/EMT64 (AMD architecture)*
> > > > > Let's put this aside for the first release. We have some stability level
> > > > > there which is supported by CruiseControl and no regression on these
> > > > > platform is enough for the first release. I'm fine to include this into M1
> > > > > if someone commit to this.
> > > > >
> > > > > *- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > > > > Windows 2003 R2, (Windows Vista?)*
> > > > >
> > > > >
> > > > >
> > > > > + 1 for Windows 2003, Windows XP. It's interesting to try on Vista but I'd
> > > > > give it some time to "grow up" before we go there.
> > > >
> > > > Pavel, I personally would vote Linux32 for the first release. If Win32
> > > > is easier to achieve, we probably can make is an internal
> > > > (intermediate) milestone for the real Linux32 release. (Actually I
> > > > don't know if Win32 is easier than Linux32).
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > > >
> > > > > *- Linux; kernel v2.4.x, v2.6.x*
> > > > >
> > > > >
> > > > >
> > > > > I'm sure Geir will vote for Linux, but I'm reluctant to put everything in
> > > > > the first milestone.
> > > > >
> > > > >
> > > > > *- (FreeBSD v???)
> > > > > *
> > > > >
> > > > > Volunteers? ;-)
> > > > >
> > > > >
> > > > >
> > > > > Thank you,
> > > > >
> > > > > Pavel Ozhdikhin
> > > > >
> > > > > Intel Managed Runtime Division
> > > > >
> > > >
> > >
> >
>
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
On 4/4/07, Alexey Varlamov <al...@gmail.com> wrote:
> 2007/4/5, Nathan Beyer <nd...@apache.org>:
> > I'll another look at this patch [1], but I can only test it on a
> > 32-bit chips. It looks like there's a change to some em_64 files, or
> > am I reading the patch wrong?
> No, those are just updates to shared ia32 and x64 files, +
> ia32-targeted Jitrino config. It is possible to test the patch on x64
> as well, but then another config file is needed.
> So, did you try how it works on PIII? Note, still no w2k support so
> you have to use linux box.
I applied the patch and am trying to run DRLVM tests on WinXP to
verify passivity. I'm still trying to get things moving on linux, but
I'm still tweaking our the 'mfence' operations.
-Nathan
>
> >
> > Alexey, are you going to add a patch to this issue [1] for your
> > additional changes, or did you already create another issue?
> Not yet, but such changes better go to separate JIRA.
>
> >
> > -Nathan
> >
> > [1] https://issues.apache.org/jira/browse/HARMONY-3246
> >
> > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > 2007/4/4, Mikhail Fursov <mi...@gmail.com>:
> > > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > >
> > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > Evgueni Brevnov wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Seems like this is not a technical discussion anyway I did some
> > > > > > > expiriments on my Fedora Core release 5 (Bordeaux) PentiumIII
> > > > > > > machine. Additionally to HARMONY-3246 it required a few modifications
> > > > > > > in sources and proper arguments to the compiler to run HelloWord and
> > > > > > > other applications. I can provide a patch with modifications to
> > > > > > > building system to build PentiumIII friendly VM. Is anyone intrested
> > > > > > > in this?
> > > > > >
> > > > > > I would like to see these modifications. I wonder what you've done in
> > > > > > port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> > > > > > They contain mfence and sfence instructions in inline assembly which
> > > > > > have to be changed to something else on P3.
> > > > > Can we produce separate binary build for P3 if it is not easy to
> > > > > replace mfence/sfence?
> > > > Jitrino can use runtime detection of CPU features supported and emit
> > > > appropriate code.
> > > Yep, it is better approach.
> > >
> > > SY, Alexey
> > >
> > > > Can we do the same with VM (check flag) to avoid multiple distributions?
> > > >
> > > > --
> > > > Mikhail Fursov
> > > >
> > >
> >
>
Re: [general] What platforms do we support?
Posted by Alexey Varlamov <al...@gmail.com>.
2007/4/5, Nathan Beyer <nd...@apache.org>:
> I'll another look at this patch [1], but I can only test it on a
> 32-bit chips. It looks like there's a change to some em_64 files, or
> am I reading the patch wrong?
No, those are just updates to shared ia32 and x64 files, +
ia32-targeted Jitrino config. It is possible to test the patch on x64
as well, but then another config file is needed.
So, did you try how it works on PIII? Note, still no w2k support so
you have to use linux box.
>
> Alexey, are you going to add a patch to this issue [1] for your
> additional changes, or did you already create another issue?
Not yet, but such changes better go to separate JIRA.
>
> -Nathan
>
> [1] https://issues.apache.org/jira/browse/HARMONY-3246
>
> On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > 2007/4/4, Mikhail Fursov <mi...@gmail.com>:
> > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > >
> > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > Evgueni Brevnov wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Seems like this is not a technical discussion anyway I did some
> > > > > > expiriments on my Fedora Core release 5 (Bordeaux) PentiumIII
> > > > > > machine. Additionally to HARMONY-3246 it required a few modifications
> > > > > > in sources and proper arguments to the compiler to run HelloWord and
> > > > > > other applications. I can provide a patch with modifications to
> > > > > > building system to build PentiumIII friendly VM. Is anyone intrested
> > > > > > in this?
> > > > >
> > > > > I would like to see these modifications. I wonder what you've done in
> > > > > port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> > > > > They contain mfence and sfence instructions in inline assembly which
> > > > > have to be changed to something else on P3.
> > > > Can we produce separate binary build for P3 if it is not easy to
> > > > replace mfence/sfence?
> > > Jitrino can use runtime detection of CPU features supported and emit
> > > appropriate code.
> > Yep, it is better approach.
> >
> > SY, Alexey
> >
> > > Can we do the same with VM (check flag) to avoid multiple distributions?
> > >
> > > --
> > > Mikhail Fursov
> > >
> >
>
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
I'll another look at this patch [1], but I can only test it on a
32-bit chips. It looks like there's a change to some em_64 files, or
am I reading the patch wrong?
Alexey, are you going to add a patch to this issue [1] for your
additional changes, or did you already create another issue?
-Nathan
[1] https://issues.apache.org/jira/browse/HARMONY-3246
On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> 2007/4/4, Mikhail Fursov <mi...@gmail.com>:
> > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > >
> > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > Evgueni Brevnov wrote:
> > > > > Hi,
> > > > >
> > > > > Seems like this is not a technical discussion anyway I did some
> > > > > expiriments on my Fedora Core release 5 (Bordeaux) PentiumIII
> > > > > machine. Additionally to HARMONY-3246 it required a few modifications
> > > > > in sources and proper arguments to the compiler to run HelloWord and
> > > > > other applications. I can provide a patch with modifications to
> > > > > building system to build PentiumIII friendly VM. Is anyone intrested
> > > > > in this?
> > > >
> > > > I would like to see these modifications. I wonder what you've done in
> > > > port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> > > > They contain mfence and sfence instructions in inline assembly which
> > > > have to be changed to something else on P3.
> > > Can we produce separate binary build for P3 if it is not easy to
> > > replace mfence/sfence?
> > Jitrino can use runtime detection of CPU features supported and emit
> > appropriate code.
> Yep, it is better approach.
>
> SY, Alexey
>
> > Can we do the same with VM (check flag) to avoid multiple distributions?
> >
> > --
> > Mikhail Fursov
> >
>
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
Mikhail,
Do mean choose which library to load with LoadLibrary() dynamically at
startup? This can be done, but that still requires platform specific
libraries?
For x64 and IA64 we have seperate platform specific binaries. For
x86 32, what would be platform specific between PIII, PIV, Centrino
etc. except the fence instructions which don't really need to exist
for any x86 processor( other than if SSE2 etc. is used ),
monitor/mwait that we don't use, and the SSE category of instructions
which could be all generated by the jit based on platform? In other
words, what do we lose if all the static binaries are PIII compatible
and additional instruction types are only generated by the jit?
Thanks,
Rana
On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> On 4/5/07, Rana Dasgupta <rd...@gmail.com> wrote:
> >
> >
> > Jitrino generates code late, the VM doesn't. So I am not sure how this
> > would work unless we link all versions of the asm's and then decide
> > which ones to call at runtime, which has a cost. My suggestion would
> > be that if we want the x86-32 bits to be PIII compatible, we should
> > only use PIII instructions ( upto SSE ) in all the static 32 bit
> > binaries. The jit can choose to generate more advanced instruction
> > sequences at runtime based on cpuid if the paltform supports it.
> >
> > Is runtime check really expensive in scenarios we have? Can all CPU
> dependent code be moved into separate library, so a component can
> decide in runtime which library to load
> during startup and avoid further checks?
>
>
> --
> Mikhail Fursov
>
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
I found this little article about using memory barriers in Windows [1]
(and XBox?). There's a mechanism for using these barriers in MSVC 2003
(7.1).
As for Linux, I think we should use the built-in memory barrier
methods [2] in the kernel. Specifically, the smp_mb() (read/write) and
smp_wmb() (write).
I believe this would give the appropriate level of abstraction for the
static code we need to run on the various architectures and OSes and
still get the best execution.
I'm working on testing this theory out right now.
-Nathan
[1] http://msdn2.microsoft.com/en-us/library/bb310595.aspx
[2] http://lxr.linux.no/source/Documentation/memory-barriers.txt
On 4/8/07, Rana Dasgupta <rd...@gmail.com> wrote:
> They are not completely no-ops. They are directives to the compiler
> not to reorder during its optimizations, though they don't generate
> instructions. If available, I think it is a better idea to use them
> instead of removing the fences. I agree, they at least allow us to
> tweak them in a platform specific way if we need them. I am not sure
> if they are both vailable on the older tools eg VS7.1 ...they are in
> VS8.
>
> While the tests are great, there is no guarantee that they are
> exercising all situations where we may need the fences. So, some
> caution is a good idea.
>
> On 4/8/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > On Sunday 08 April 2007 06:36 Xiao-Feng Li wrote:
> > > On 4/8/07, Nathan Beyer <nd...@apache.org> wrote:
> > > > Well, all of the mfence operations seem to be wrapped in helper
> > > > functions, so it should be a fairly targeted extraction that can
> > > > easily be tweaked as we go forward.
> > > >
> > > > In the 'atomics.h' file, the helper functions on EM64/Win64 use the
> > > > intrinsic functions "_ReadWriteBarrier" and "_WriteBarrier"? Could we
> > > > just use those same functions on all platforms? They seem to be
> > > > available everywhere.
> > >
> > > Good idea. Those fence instructions have their respetive usage but
> > > could be useless for an architecture with a stronger memory model. To
> > > put them into macro or intrinsic would be a better approach than to
> > > simply remove them. (In case of the architectures that use different
> > > atomic mechanism like LL/CS vs. CAS, we may have to rewrite some code
> > > sequence, but that's another issue.)
> >
> > My recent discovery after reading MSDN is that _[Read]WriteBarrier intrinsics
> > which were introduced in MSVC 2005 are a NOOP in the code. These intrinsics
> > are only directives to the compiler optimizer and are somewhat similar to the
> > volatile keyword in the code, but less powerful and intrusive. When reaching
> > _[Read]WriteBarrier intrinsic, compiler makes sure that all necessary reads
> > and writes are made to the memory, so the variables are not cached on the
> > registers in the place where intrinsic is put. No code is generated for them.
> >
> > To actually insert mfence into the code MSVC has another intrinsic
> > _mm_mfence() and it will generate a true mfence in the code no matter which
> > architecture is chosen for the compilation.
> >
> > Answering Nathan's question about my experiment, yes I commented out
> > [Read]WriteBarrier implementation for 64-bit systems when I done it,
> > including the implementation for windows64 which used those NOOP intrinsics
> > _[Read]WriteBarrier.
> >
> > This is actually another sign that mfence and sfence are probably not needed
> > in atomics.h since all the way since windows64 port was enabled, it used
> > these NOOP compiler directives for [Read]WriteBarrier and there were no race
> > conditions noticed compared to Linux64.
> >
> > > > -Nathan
> > > >
> > > > On 4/6/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > Gregory,
> > > > > First, the experiments are really useful and increase confidence
> > > > > more than any amount of discussion can. Thanks.
> > > > > Here is my understanding of some processor basics, which is not a
> > > > > whole lot. The x86 memory model is actually quite similar for P3, P4,
> > > > > Xeon processors for write back caches( most ) and non write combining
> > > > > memory ( most ).
> > > > > Some things always hold true...writes are committed in program
> > > > > order( they are not done speculatively...so if a thread/processor does
> > > > > 3 updates in the program stream, they will be in order except for
> > > > > streaming writes like in SSE2 instructions and some rare string
> > > > > operations which are unordered ), but reads can be in any order.
> > > > > Reads can pass buffered writes, but it is almost certainly true that
> > > > > this will not happen on the same location. Reads/writes cannot pass
> > > > > instructions with a lock prefix, etc.
> > > > > This is true of a single processor/thread, but for SMP's the
> > > > > guarantees are weaker. The above is true for each processor, but not
> > > > > for all the processors together. Writes from one processor can be
> > > > > unordered with respect to writes from another processor. This is OK
> > > > > because when we have a true contention between writes to the same
> > > > > memory location across threads, we always explicitly use critical
> > > > > sections and locks. We never rely on the processor ordering. Any VM
> > > > > code that does not do this is possibly wrong, and if we find it, we
> > > > > will need to change it.
> > > > > The fence instructions ( sfence and mfence ) force all the pending
> > > > > and queued upstore and load/store instructions to finish before the
> > > > > next instruction( after the fence ) follows. They are not true lock
> > > > > instructions and are much cheaper...and they can only prevent the
> > > > > following instructions from being surprised by earlier instructions
> > > > > that have not yet been committed because of some complex
> > > > > cache/buffer/speculation behaviour. For example, they enforce volatile
> > > > > behaviour in the concurrent.atomics classes etc. On PIII, if we don't
> > > > > use the SSE type instructions, given the simpler cache and write
> > > > > buffer architecture on the older PIII machines, there is a good chance
> > > > > that we will be OK. This is unlikely to be true on P4, HT and
> > > > > multicore systems.
> > > > > So we should just try operating without them on the PIII only( not
> > > > > sfence, which exists on PIII, but lfence which is used for
> > > > > readwritebarriers), and if Nathan or we find concurrency related
> > > > > failures in some tests down the line, we will need to put locks in
> > > > > that part of the code. Locks are a really expensive way to do this
> > > > > type of serialization, but that's the only option.
> > > > >
> > > > > Thanks,
> > > > > Rana
> > > > >
> > > > > On 4/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > On Friday 06 April 2007 02:39 Rana Dasgupta wrote:
> > > > > > > On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > > > On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> > > > > > > > > On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > > > > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > > > > > > > > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > > > > > > On 4/4/07, Alexey Petrenko <al...@gmail.com>
> > wrote:
> > > > > > > > > > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > > > > > > > > > I would like to see these modifications. I wonder
> > > > > > > > > > > > > > > > what you've done in
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > > > > > > > > > vmcore/include/atomics.h. They contain mfence and
> > > > > > > > > > > > > > sfence instructions in inline assembly which have to
> > > > > > > > > > > > > > be changed to something else on P3.
> > > > > > > > > > >
> > > > > > > > > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is
> > > > > > > > > > > already strongly ordered for writes ?
> > > > > > > > > >
> > > > > > > > > > What about MemoryReadWriteBarrier()? If you know, what kind
> > > > > > > > > > of code should be used for this in P3?
> > > > > > > > >
> > > > > > > > > One of the compiler guys can confirm this. But I don't believe
> > > > > > > > > that you need to worry about any of the fence instructions
> > > > > > > > > fence on any of the PIII, PIV genuine intel procs unless you
> > > > > > > > > are using streaming mode ( SIMD ) instructions which are weakly
> > > > > > > > > ordered.
> > > > > > > >
> > > > > > > > I actually grepped the use for MemoryReadWriteBarrier,
> > > > > > > > MemoryWriteBarrier and apr_memory_rw_barrier functions which are
> > > > > > > > wrappers to mfence/sfence instructions. They aren't used in the
> > > > > > > > code which uses SSE2 in any way.
> > > > > > > >
> > > > > > > > - The apr_memory_rw_barrier (executes mfence) function is used in
> > > > > > > > thin locks implementation in threading code.
> > > > > > > >
> > > > > > > > - MemoryReadWriteBarrier (executes mfence) is used in
> > > > > > > > org.apache.harmony.util.concurrent natives implementation after
> > > > > > > > writing/reading int/long/object fields via JNI.
> > > > > > > >
> > > > > > > > - MemoryWriteBarrier (executes sfence) is used in classloader for
> > > > > > > > fast management of classes collection and in strings pool for the
> > > > > > > > same reason.
> > > > > > > >
> > > > > > > > In all three cases SSE2 is not involved in any way, simply loads
> > > > > > > > and stores are done with the memory. According to you in all of
> > > > > > > > those cases memory barriers are not needed. I am just confused
> > > > > > > > then why were they inserted in those places?
> > > > > > >
> > > > > > > I don't know the answer to this question ...unless it was intended
> > > > > > > to cover clones etc. that don't fully support the writeback
> > > > > > > model...
> > > > > >
> > > > > > I should have put the question in a different way. I didn't actually
> > > > > > mean that you should know why some code is written in VM. I don't
> > > > > > know why some code is written in many places including those I
> > > > > > mentioned.
> > > > > >
> > > > > > The question should actually be like, should we actually remove
> > > > > > mfence and sfence assembly instructions from the VM sources for
> > > > > > x86/x86_64 platforms? I commented mfence in
> > > > > > port/src/thread/linux/apr_thread_ext.c and mfence/sfence in
> > > > > > vmcore/include/atomics.h and ran VM tests on 5 different SMP boxes
> > > > > > with no less than 4 logical CPUs on each of them (2 win32, linux32,
> > > > > > windows64 and linux64). Tests seem to work just fine without mfence
> > > > > > and sfence in VM code.
> > > > > >
> > > > > > With these instructions removed from the code there shall be no
> > > > > > problem with P3 port on VM side. It seems they are actually
> > > > > > unnecessary and were inserted for a reason that they help on SMP to
> > > > > > synchronize caches. After your explanation that they are actually
> > > > > > needed only when SSE2 is involved, it seems (and my tests show this)
> > > > > > that they are just not needed.
> > > > > >
> > > > > > --
> > > > > > Gregory
> >
> > --
> > Gregory
> >
>
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
They are not completely no-ops. They are directives to the compiler
not to reorder during its optimizations, though they don't generate
instructions. If available, I think it is a better idea to use them
instead of removing the fences. I agree, they at least allow us to
tweak them in a platform specific way if we need them. I am not sure
if they are both vailable on the older tools eg VS7.1 ...they are in
VS8.
While the tests are great, there is no guarantee that they are
exercising all situations where we may need the fences. So, some
caution is a good idea.
On 4/8/07, Gregory Shimansky <gs...@gmail.com> wrote:
> On Sunday 08 April 2007 06:36 Xiao-Feng Li wrote:
> > On 4/8/07, Nathan Beyer <nd...@apache.org> wrote:
> > > Well, all of the mfence operations seem to be wrapped in helper
> > > functions, so it should be a fairly targeted extraction that can
> > > easily be tweaked as we go forward.
> > >
> > > In the 'atomics.h' file, the helper functions on EM64/Win64 use the
> > > intrinsic functions "_ReadWriteBarrier" and "_WriteBarrier"? Could we
> > > just use those same functions on all platforms? They seem to be
> > > available everywhere.
> >
> > Good idea. Those fence instructions have their respetive usage but
> > could be useless for an architecture with a stronger memory model. To
> > put them into macro or intrinsic would be a better approach than to
> > simply remove them. (In case of the architectures that use different
> > atomic mechanism like LL/CS vs. CAS, we may have to rewrite some code
> > sequence, but that's another issue.)
>
> My recent discovery after reading MSDN is that _[Read]WriteBarrier intrinsics
> which were introduced in MSVC 2005 are a NOOP in the code. These intrinsics
> are only directives to the compiler optimizer and are somewhat similar to the
> volatile keyword in the code, but less powerful and intrusive. When reaching
> _[Read]WriteBarrier intrinsic, compiler makes sure that all necessary reads
> and writes are made to the memory, so the variables are not cached on the
> registers in the place where intrinsic is put. No code is generated for them.
>
> To actually insert mfence into the code MSVC has another intrinsic
> _mm_mfence() and it will generate a true mfence in the code no matter which
> architecture is chosen for the compilation.
>
> Answering Nathan's question about my experiment, yes I commented out
> [Read]WriteBarrier implementation for 64-bit systems when I done it,
> including the implementation for windows64 which used those NOOP intrinsics
> _[Read]WriteBarrier.
>
> This is actually another sign that mfence and sfence are probably not needed
> in atomics.h since all the way since windows64 port was enabled, it used
> these NOOP compiler directives for [Read]WriteBarrier and there were no race
> conditions noticed compared to Linux64.
>
> > > -Nathan
> > >
> > > On 4/6/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > Gregory,
> > > > First, the experiments are really useful and increase confidence
> > > > more than any amount of discussion can. Thanks.
> > > > Here is my understanding of some processor basics, which is not a
> > > > whole lot. The x86 memory model is actually quite similar for P3, P4,
> > > > Xeon processors for write back caches( most ) and non write combining
> > > > memory ( most ).
> > > > Some things always hold true...writes are committed in program
> > > > order( they are not done speculatively...so if a thread/processor does
> > > > 3 updates in the program stream, they will be in order except for
> > > > streaming writes like in SSE2 instructions and some rare string
> > > > operations which are unordered ), but reads can be in any order.
> > > > Reads can pass buffered writes, but it is almost certainly true that
> > > > this will not happen on the same location. Reads/writes cannot pass
> > > > instructions with a lock prefix, etc.
> > > > This is true of a single processor/thread, but for SMP's the
> > > > guarantees are weaker. The above is true for each processor, but not
> > > > for all the processors together. Writes from one processor can be
> > > > unordered with respect to writes from another processor. This is OK
> > > > because when we have a true contention between writes to the same
> > > > memory location across threads, we always explicitly use critical
> > > > sections and locks. We never rely on the processor ordering. Any VM
> > > > code that does not do this is possibly wrong, and if we find it, we
> > > > will need to change it.
> > > > The fence instructions ( sfence and mfence ) force all the pending
> > > > and queued upstore and load/store instructions to finish before the
> > > > next instruction( after the fence ) follows. They are not true lock
> > > > instructions and are much cheaper...and they can only prevent the
> > > > following instructions from being surprised by earlier instructions
> > > > that have not yet been committed because of some complex
> > > > cache/buffer/speculation behaviour. For example, they enforce volatile
> > > > behaviour in the concurrent.atomics classes etc. On PIII, if we don't
> > > > use the SSE type instructions, given the simpler cache and write
> > > > buffer architecture on the older PIII machines, there is a good chance
> > > > that we will be OK. This is unlikely to be true on P4, HT and
> > > > multicore systems.
> > > > So we should just try operating without them on the PIII only( not
> > > > sfence, which exists on PIII, but lfence which is used for
> > > > readwritebarriers), and if Nathan or we find concurrency related
> > > > failures in some tests down the line, we will need to put locks in
> > > > that part of the code. Locks are a really expensive way to do this
> > > > type of serialization, but that's the only option.
> > > >
> > > > Thanks,
> > > > Rana
> > > >
> > > > On 4/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > On Friday 06 April 2007 02:39 Rana Dasgupta wrote:
> > > > > > On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > > On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> > > > > > > > On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > > > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > > > > > > > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > > > > > On 4/4/07, Alexey Petrenko <al...@gmail.com>
> wrote:
> > > > > > > > > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > > > > > > > > I would like to see these modifications. I wonder
> > > > > > > > > > > > > > > what you've done in
> > > > > > > > > > > > >
> > > > > > > > > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > > > > > > > > vmcore/include/atomics.h. They contain mfence and
> > > > > > > > > > > > > sfence instructions in inline assembly which have to
> > > > > > > > > > > > > be changed to something else on P3.
> > > > > > > > > >
> > > > > > > > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is
> > > > > > > > > > already strongly ordered for writes ?
> > > > > > > > >
> > > > > > > > > What about MemoryReadWriteBarrier()? If you know, what kind
> > > > > > > > > of code should be used for this in P3?
> > > > > > > >
> > > > > > > > One of the compiler guys can confirm this. But I don't believe
> > > > > > > > that you need to worry about any of the fence instructions
> > > > > > > > fence on any of the PIII, PIV genuine intel procs unless you
> > > > > > > > are using streaming mode ( SIMD ) instructions which are weakly
> > > > > > > > ordered.
> > > > > > >
> > > > > > > I actually grepped the use for MemoryReadWriteBarrier,
> > > > > > > MemoryWriteBarrier and apr_memory_rw_barrier functions which are
> > > > > > > wrappers to mfence/sfence instructions. They aren't used in the
> > > > > > > code which uses SSE2 in any way.
> > > > > > >
> > > > > > > - The apr_memory_rw_barrier (executes mfence) function is used in
> > > > > > > thin locks implementation in threading code.
> > > > > > >
> > > > > > > - MemoryReadWriteBarrier (executes mfence) is used in
> > > > > > > org.apache.harmony.util.concurrent natives implementation after
> > > > > > > writing/reading int/long/object fields via JNI.
> > > > > > >
> > > > > > > - MemoryWriteBarrier (executes sfence) is used in classloader for
> > > > > > > fast management of classes collection and in strings pool for the
> > > > > > > same reason.
> > > > > > >
> > > > > > > In all three cases SSE2 is not involved in any way, simply loads
> > > > > > > and stores are done with the memory. According to you in all of
> > > > > > > those cases memory barriers are not needed. I am just confused
> > > > > > > then why were they inserted in those places?
> > > > > >
> > > > > > I don't know the answer to this question ...unless it was intended
> > > > > > to cover clones etc. that don't fully support the writeback
> > > > > > model...
> > > > >
> > > > > I should have put the question in a different way. I didn't actually
> > > > > mean that you should know why some code is written in VM. I don't
> > > > > know why some code is written in many places including those I
> > > > > mentioned.
> > > > >
> > > > > The question should actually be like, should we actually remove
> > > > > mfence and sfence assembly instructions from the VM sources for
> > > > > x86/x86_64 platforms? I commented mfence in
> > > > > port/src/thread/linux/apr_thread_ext.c and mfence/sfence in
> > > > > vmcore/include/atomics.h and ran VM tests on 5 different SMP boxes
> > > > > with no less than 4 logical CPUs on each of them (2 win32, linux32,
> > > > > windows64 and linux64). Tests seem to work just fine without mfence
> > > > > and sfence in VM code.
> > > > >
> > > > > With these instructions removed from the code there shall be no
> > > > > problem with P3 port on VM side. It seems they are actually
> > > > > unnecessary and were inserted for a reason that they help on SMP to
> > > > > synchronize caches. After your explanation that they are actually
> > > > > needed only when SSE2 is involved, it seems (and my tests show this)
> > > > > that they are just not needed.
> > > > >
> > > > > --
> > > > > Gregory
>
> --
> Gregory
>
Re: [general] What platforms do we support?
Posted by Gregory Shimansky <gs...@gmail.com>.
On Sunday 08 April 2007 06:36 Xiao-Feng Li wrote:
> On 4/8/07, Nathan Beyer <nd...@apache.org> wrote:
> > Well, all of the mfence operations seem to be wrapped in helper
> > functions, so it should be a fairly targeted extraction that can
> > easily be tweaked as we go forward.
> >
> > In the 'atomics.h' file, the helper functions on EM64/Win64 use the
> > intrinsic functions "_ReadWriteBarrier" and "_WriteBarrier"? Could we
> > just use those same functions on all platforms? They seem to be
> > available everywhere.
>
> Good idea. Those fence instructions have their respetive usage but
> could be useless for an architecture with a stronger memory model. To
> put them into macro or intrinsic would be a better approach than to
> simply remove them. (In case of the architectures that use different
> atomic mechanism like LL/CS vs. CAS, we may have to rewrite some code
> sequence, but that's another issue.)
My recent discovery after reading MSDN is that _[Read]WriteBarrier intrinsics
which were introduced in MSVC 2005 are a NOOP in the code. These intrinsics
are only directives to the compiler optimizer and are somewhat similar to the
volatile keyword in the code, but less powerful and intrusive. When reaching
_[Read]WriteBarrier intrinsic, compiler makes sure that all necessary reads
and writes are made to the memory, so the variables are not cached on the
registers in the place where intrinsic is put. No code is generated for them.
To actually insert mfence into the code MSVC has another intrinsic
_mm_mfence() and it will generate a true mfence in the code no matter which
architecture is chosen for the compilation.
Answering Nathan's question about my experiment, yes I commented out
[Read]WriteBarrier implementation for 64-bit systems when I done it,
including the implementation for windows64 which used those NOOP intrinsics
_[Read]WriteBarrier.
This is actually another sign that mfence and sfence are probably not needed
in atomics.h since all the way since windows64 port was enabled, it used
these NOOP compiler directives for [Read]WriteBarrier and there were no race
conditions noticed compared to Linux64.
> > -Nathan
> >
> > On 4/6/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > Gregory,
> > > First, the experiments are really useful and increase confidence
> > > more than any amount of discussion can. Thanks.
> > > Here is my understanding of some processor basics, which is not a
> > > whole lot. The x86 memory model is actually quite similar for P3, P4,
> > > Xeon processors for write back caches( most ) and non write combining
> > > memory ( most ).
> > > Some things always hold true...writes are committed in program
> > > order( they are not done speculatively...so if a thread/processor does
> > > 3 updates in the program stream, they will be in order except for
> > > streaming writes like in SSE2 instructions and some rare string
> > > operations which are unordered ), but reads can be in any order.
> > > Reads can pass buffered writes, but it is almost certainly true that
> > > this will not happen on the same location. Reads/writes cannot pass
> > > instructions with a lock prefix, etc.
> > > This is true of a single processor/thread, but for SMP's the
> > > guarantees are weaker. The above is true for each processor, but not
> > > for all the processors together. Writes from one processor can be
> > > unordered with respect to writes from another processor. This is OK
> > > because when we have a true contention between writes to the same
> > > memory location across threads, we always explicitly use critical
> > > sections and locks. We never rely on the processor ordering. Any VM
> > > code that does not do this is possibly wrong, and if we find it, we
> > > will need to change it.
> > > The fence instructions ( sfence and mfence ) force all the pending
> > > and queued upstore and load/store instructions to finish before the
> > > next instruction( after the fence ) follows. They are not true lock
> > > instructions and are much cheaper...and they can only prevent the
> > > following instructions from being surprised by earlier instructions
> > > that have not yet been committed because of some complex
> > > cache/buffer/speculation behaviour. For example, they enforce volatile
> > > behaviour in the concurrent.atomics classes etc. On PIII, if we don't
> > > use the SSE type instructions, given the simpler cache and write
> > > buffer architecture on the older PIII machines, there is a good chance
> > > that we will be OK. This is unlikely to be true on P4, HT and
> > > multicore systems.
> > > So we should just try operating without them on the PIII only( not
> > > sfence, which exists on PIII, but lfence which is used for
> > > readwritebarriers), and if Nathan or we find concurrency related
> > > failures in some tests down the line, we will need to put locks in
> > > that part of the code. Locks are a really expensive way to do this
> > > type of serialization, but that's the only option.
> > >
> > > Thanks,
> > > Rana
> > >
> > > On 4/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > On Friday 06 April 2007 02:39 Rana Dasgupta wrote:
> > > > > On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> > > > > > > On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > > > > > > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > > > > On 4/4/07, Alexey Petrenko <al...@gmail.com>
wrote:
> > > > > > > > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > > > > > > > I would like to see these modifications. I wonder
> > > > > > > > > > > > > > what you've done in
> > > > > > > > > > > >
> > > > > > > > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > > > > > > > vmcore/include/atomics.h. They contain mfence and
> > > > > > > > > > > > sfence instructions in inline assembly which have to
> > > > > > > > > > > > be changed to something else on P3.
> > > > > > > > >
> > > > > > > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is
> > > > > > > > > already strongly ordered for writes ?
> > > > > > > >
> > > > > > > > What about MemoryReadWriteBarrier()? If you know, what kind
> > > > > > > > of code should be used for this in P3?
> > > > > > >
> > > > > > > One of the compiler guys can confirm this. But I don't believe
> > > > > > > that you need to worry about any of the fence instructions
> > > > > > > fence on any of the PIII, PIV genuine intel procs unless you
> > > > > > > are using streaming mode ( SIMD ) instructions which are weakly
> > > > > > > ordered.
> > > > > >
> > > > > > I actually grepped the use for MemoryReadWriteBarrier,
> > > > > > MemoryWriteBarrier and apr_memory_rw_barrier functions which are
> > > > > > wrappers to mfence/sfence instructions. They aren't used in the
> > > > > > code which uses SSE2 in any way.
> > > > > >
> > > > > > - The apr_memory_rw_barrier (executes mfence) function is used in
> > > > > > thin locks implementation in threading code.
> > > > > >
> > > > > > - MemoryReadWriteBarrier (executes mfence) is used in
> > > > > > org.apache.harmony.util.concurrent natives implementation after
> > > > > > writing/reading int/long/object fields via JNI.
> > > > > >
> > > > > > - MemoryWriteBarrier (executes sfence) is used in classloader for
> > > > > > fast management of classes collection and in strings pool for the
> > > > > > same reason.
> > > > > >
> > > > > > In all three cases SSE2 is not involved in any way, simply loads
> > > > > > and stores are done with the memory. According to you in all of
> > > > > > those cases memory barriers are not needed. I am just confused
> > > > > > then why were they inserted in those places?
> > > > >
> > > > > I don't know the answer to this question ...unless it was intended
> > > > > to cover clones etc. that don't fully support the writeback
> > > > > model...
> > > >
> > > > I should have put the question in a different way. I didn't actually
> > > > mean that you should know why some code is written in VM. I don't
> > > > know why some code is written in many places including those I
> > > > mentioned.
> > > >
> > > > The question should actually be like, should we actually remove
> > > > mfence and sfence assembly instructions from the VM sources for
> > > > x86/x86_64 platforms? I commented mfence in
> > > > port/src/thread/linux/apr_thread_ext.c and mfence/sfence in
> > > > vmcore/include/atomics.h and ran VM tests on 5 different SMP boxes
> > > > with no less than 4 logical CPUs on each of them (2 win32, linux32,
> > > > windows64 and linux64). Tests seem to work just fine without mfence
> > > > and sfence in VM code.
> > > >
> > > > With these instructions removed from the code there shall be no
> > > > problem with P3 port on VM side. It seems they are actually
> > > > unnecessary and were inserted for a reason that they help on SMP to
> > > > synchronize caches. After your explanation that they are actually
> > > > needed only when SSE2 is involved, it seems (and my tests show this)
> > > > that they are just not needed.
> > > >
> > > > --
> > > > Gregory
--
Gregory
Re: [general] What platforms do we support?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/8/07, Nathan Beyer <nd...@apache.org> wrote:
> Well, all of the mfence operations seem to be wrapped in helper
> functions, so it should be a fairly targeted extraction that can
> easily be tweaked as we go forward.
>
> In the 'atomics.h' file, the helper functions on EM64/Win64 use the
> intrinsic functions "_ReadWriteBarrier" and "_WriteBarrier"? Could we
> just use those same functions on all platforms? They seem to be
> available everywhere.
Good idea. Those fence instructions have their respetive usage but
could be useless for an architecture with a stronger memory model. To
put them into macro or intrinsic would be a better approach than to
simply remove them. (In case of the architectures that use different
atomic mechanism like LL/CS vs. CAS, we may have to rewrite some code
sequence, but that's another issue.)
Thanks.
xiaofeng
> -Nathan
>
> On 4/6/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > Gregory,
> > First, the experiments are really useful and increase confidence
> > more than any amount of discussion can. Thanks.
> > Here is my understanding of some processor basics, which is not a
> > whole lot. The x86 memory model is actually quite similar for P3, P4,
> > Xeon processors for write back caches( most ) and non write combining
> > memory ( most ).
> > Some things always hold true...writes are committed in program
> > order( they are not done speculatively...so if a thread/processor does
> > 3 updates in the program stream, they will be in order except for
> > streaming writes like in SSE2 instructions and some rare string
> > operations which are unordered ), but reads can be in any order.
> > Reads can pass buffered writes, but it is almost certainly true that
> > this will not happen on the same location. Reads/writes cannot pass
> > instructions with a lock prefix, etc.
> > This is true of a single processor/thread, but for SMP's the
> > guarantees are weaker. The above is true for each processor, but not
> > for all the processors together. Writes from one processor can be
> > unordered with respect to writes from another processor. This is OK
> > because when we have a true contention between writes to the same
> > memory location across threads, we always explicitly use critical
> > sections and locks. We never rely on the processor ordering. Any VM
> > code that does not do this is possibly wrong, and if we find it, we
> > will need to change it.
> > The fence instructions ( sfence and mfence ) force all the pending
> > and queued upstore and load/store instructions to finish before the
> > next instruction( after the fence ) follows. They are not true lock
> > instructions and are much cheaper...and they can only prevent the
> > following instructions from being surprised by earlier instructions
> > that have not yet been committed because of some complex
> > cache/buffer/speculation behaviour. For example, they enforce volatile
> > behaviour in the concurrent.atomics classes etc. On PIII, if we don't
> > use the SSE type instructions, given the simpler cache and write
> > buffer architecture on the older PIII machines, there is a good chance
> > that we will be OK. This is unlikely to be true on P4, HT and
> > multicore systems.
> > So we should just try operating without them on the PIII only( not
> > sfence, which exists on PIII, but lfence which is used for
> > readwritebarriers), and if Nathan or we find concurrency related
> > failures in some tests down the line, we will need to put locks in
> > that part of the code. Locks are a really expensive way to do this
> > type of serialization, but that's the only option.
> >
> > Thanks,
> > Rana
> >
> >
> >
> > On 4/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > On Friday 06 April 2007 02:39 Rana Dasgupta wrote:
> > > > On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> > > > > > On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > > > > > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > > > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > > > > > > I would like to see these modifications. I wonder what
> > > > > > > > > > > > > you've done in
> > > > > > > > > > >
> > > > > > > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > > > > > > vmcore/include/atomics.h. They contain mfence and sfence
> > > > > > > > > > > instructions in inline assembly which have to be changed to
> > > > > > > > > > > something else on P3.
> > > > > > > >
> > > > > > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > > > > > > > strongly ordered for writes ?
> > > > > > >
> > > > > > > What about MemoryReadWriteBarrier()? If you know, what kind of code
> > > > > > > should be used for this in P3?
> > > > > >
> > > > > > One of the compiler guys can confirm this. But I don't believe that
> > > > > > you need to worry about any of the fence instructions fence on any of
> > > > > > the PIII, PIV genuine intel procs unless you are using streaming mode
> > > > > > ( SIMD ) instructions which are weakly ordered.
> > > > >
> > > > > I actually grepped the use for MemoryReadWriteBarrier, MemoryWriteBarrier
> > > > > and apr_memory_rw_barrier functions which are wrappers to mfence/sfence
> > > > > instructions. They aren't used in the code which uses SSE2 in any way.
> > > > >
> > > > > - The apr_memory_rw_barrier (executes mfence) function is used in thin
> > > > > locks implementation in threading code.
> > > > >
> > > > > - MemoryReadWriteBarrier (executes mfence) is used in
> > > > > org.apache.harmony.util.concurrent natives implementation after
> > > > > writing/reading int/long/object fields via JNI.
> > > > >
> > > > > - MemoryWriteBarrier (executes sfence) is used in classloader for fast
> > > > > management of classes collection and in strings pool for the same reason.
> > > > >
> > > > > In all three cases SSE2 is not involved in any way, simply loads and
> > > > > stores are done with the memory. According to you in all of those cases
> > > > > memory barriers are not needed. I am just confused then why were they
> > > > > inserted in those places?
> > > >
> > > > I don't know the answer to this question ...unless it was intended to
> > > > cover clones etc. that don't fully support the writeback model...
> > >
> > > I should have put the question in a different way. I didn't actually mean that
> > > you should know why some code is written in VM. I don't know why some code is
> > > written in many places including those I mentioned.
> > >
> > > The question should actually be like, should we actually remove mfence and
> > > sfence assembly instructions from the VM sources for x86/x86_64 platforms? I
> > > commented mfence in port/src/thread/linux/apr_thread_ext.c and mfence/sfence
> > > in vmcore/include/atomics.h and ran VM tests on 5 different SMP boxes with no
> > > less than 4 logical CPUs on each of them (2 win32, linux32, windows64 and
> > > linux64). Tests seem to work just fine without mfence and sfence in VM code.
> > >
> > > With these instructions removed from the code there shall be no problem with
> > > P3 port on VM side. It seems they are actually unnecessary and were inserted
> > > for a reason that they help on SMP to synchronize caches. After your
> > > explanation that they are actually needed only when SSE2 is involved, it
> > > seems (and my tests show this) that they are just not needed.
> > >
> > > --
> > > Gregory
> > >
> >
>
--
http://xiao-feng.blogspot.com
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
Well, all of the mfence operations seem to be wrapped in helper
functions, so it should be a fairly targeted extraction that can
easily be tweaked as we go forward.
In the 'atomics.h' file, the helper functions on EM64/Win64 use the
intrinsic functions "_ReadWriteBarrier" and "_WriteBarrier"? Could we
just use those same functions on all platforms? They seem to be
available everywhere.
-Nathan
On 4/6/07, Rana Dasgupta <rd...@gmail.com> wrote:
> Gregory,
> First, the experiments are really useful and increase confidence
> more than any amount of discussion can. Thanks.
> Here is my understanding of some processor basics, which is not a
> whole lot. The x86 memory model is actually quite similar for P3, P4,
> Xeon processors for write back caches( most ) and non write combining
> memory ( most ).
> Some things always hold true...writes are committed in program
> order( they are not done speculatively...so if a thread/processor does
> 3 updates in the program stream, they will be in order except for
> streaming writes like in SSE2 instructions and some rare string
> operations which are unordered ), but reads can be in any order.
> Reads can pass buffered writes, but it is almost certainly true that
> this will not happen on the same location. Reads/writes cannot pass
> instructions with a lock prefix, etc.
> This is true of a single processor/thread, but for SMP's the
> guarantees are weaker. The above is true for each processor, but not
> for all the processors together. Writes from one processor can be
> unordered with respect to writes from another processor. This is OK
> because when we have a true contention between writes to the same
> memory location across threads, we always explicitly use critical
> sections and locks. We never rely on the processor ordering. Any VM
> code that does not do this is possibly wrong, and if we find it, we
> will need to change it.
> The fence instructions ( sfence and mfence ) force all the pending
> and queued upstore and load/store instructions to finish before the
> next instruction( after the fence ) follows. They are not true lock
> instructions and are much cheaper...and they can only prevent the
> following instructions from being surprised by earlier instructions
> that have not yet been committed because of some complex
> cache/buffer/speculation behaviour. For example, they enforce volatile
> behaviour in the concurrent.atomics classes etc. On PIII, if we don't
> use the SSE type instructions, given the simpler cache and write
> buffer architecture on the older PIII machines, there is a good chance
> that we will be OK. This is unlikely to be true on P4, HT and
> multicore systems.
> So we should just try operating without them on the PIII only( not
> sfence, which exists on PIII, but lfence which is used for
> readwritebarriers), and if Nathan or we find concurrency related
> failures in some tests down the line, we will need to put locks in
> that part of the code. Locks are a really expensive way to do this
> type of serialization, but that's the only option.
>
> Thanks,
> Rana
>
>
>
> On 4/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > On Friday 06 April 2007 02:39 Rana Dasgupta wrote:
> > > On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> > > > > On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > > > > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > > > > > I would like to see these modifications. I wonder what
> > > > > > > > > > > > you've done in
> > > > > > > > > >
> > > > > > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > > > > > vmcore/include/atomics.h. They contain mfence and sfence
> > > > > > > > > > instructions in inline assembly which have to be changed to
> > > > > > > > > > something else on P3.
> > > > > > >
> > > > > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > > > > > > strongly ordered for writes ?
> > > > > >
> > > > > > What about MemoryReadWriteBarrier()? If you know, what kind of code
> > > > > > should be used for this in P3?
> > > > >
> > > > > One of the compiler guys can confirm this. But I don't believe that
> > > > > you need to worry about any of the fence instructions fence on any of
> > > > > the PIII, PIV genuine intel procs unless you are using streaming mode
> > > > > ( SIMD ) instructions which are weakly ordered.
> > > >
> > > > I actually grepped the use for MemoryReadWriteBarrier, MemoryWriteBarrier
> > > > and apr_memory_rw_barrier functions which are wrappers to mfence/sfence
> > > > instructions. They aren't used in the code which uses SSE2 in any way.
> > > >
> > > > - The apr_memory_rw_barrier (executes mfence) function is used in thin
> > > > locks implementation in threading code.
> > > >
> > > > - MemoryReadWriteBarrier (executes mfence) is used in
> > > > org.apache.harmony.util.concurrent natives implementation after
> > > > writing/reading int/long/object fields via JNI.
> > > >
> > > > - MemoryWriteBarrier (executes sfence) is used in classloader for fast
> > > > management of classes collection and in strings pool for the same reason.
> > > >
> > > > In all three cases SSE2 is not involved in any way, simply loads and
> > > > stores are done with the memory. According to you in all of those cases
> > > > memory barriers are not needed. I am just confused then why were they
> > > > inserted in those places?
> > >
> > > I don't know the answer to this question ...unless it was intended to
> > > cover clones etc. that don't fully support the writeback model...
> >
> > I should have put the question in a different way. I didn't actually mean that
> > you should know why some code is written in VM. I don't know why some code is
> > written in many places including those I mentioned.
> >
> > The question should actually be like, should we actually remove mfence and
> > sfence assembly instructions from the VM sources for x86/x86_64 platforms? I
> > commented mfence in port/src/thread/linux/apr_thread_ext.c and mfence/sfence
> > in vmcore/include/atomics.h and ran VM tests on 5 different SMP boxes with no
> > less than 4 logical CPUs on each of them (2 win32, linux32, windows64 and
> > linux64). Tests seem to work just fine without mfence and sfence in VM code.
> >
> > With these instructions removed from the code there shall be no problem with
> > P3 port on VM side. It seems they are actually unnecessary and were inserted
> > for a reason that they help on SMP to synchronize caches. After your
> > explanation that they are actually needed only when SSE2 is involved, it
> > seems (and my tests show this) that they are just not needed.
> >
> > --
> > Gregory
> >
>
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
Gregory,
First, the experiments are really useful and increase confidence
more than any amount of discussion can. Thanks.
Here is my understanding of some processor basics, which is not a
whole lot. The x86 memory model is actually quite similar for P3, P4,
Xeon processors for write back caches( most ) and non write combining
memory ( most ).
Some things always hold true...writes are committed in program
order( they are not done speculatively...so if a thread/processor does
3 updates in the program stream, they will be in order except for
streaming writes like in SSE2 instructions and some rare string
operations which are unordered ), but reads can be in any order.
Reads can pass buffered writes, but it is almost certainly true that
this will not happen on the same location. Reads/writes cannot pass
instructions with a lock prefix, etc.
This is true of a single processor/thread, but for SMP's the
guarantees are weaker. The above is true for each processor, but not
for all the processors together. Writes from one processor can be
unordered with respect to writes from another processor. This is OK
because when we have a true contention between writes to the same
memory location across threads, we always explicitly use critical
sections and locks. We never rely on the processor ordering. Any VM
code that does not do this is possibly wrong, and if we find it, we
will need to change it.
The fence instructions ( sfence and mfence ) force all the pending
and queued upstore and load/store instructions to finish before the
next instruction( after the fence ) follows. They are not true lock
instructions and are much cheaper...and they can only prevent the
following instructions from being surprised by earlier instructions
that have not yet been committed because of some complex
cache/buffer/speculation behaviour. For example, they enforce volatile
behaviour in the concurrent.atomics classes etc. On PIII, if we don't
use the SSE type instructions, given the simpler cache and write
buffer architecture on the older PIII machines, there is a good chance
that we will be OK. This is unlikely to be true on P4, HT and
multicore systems.
So we should just try operating without them on the PIII only( not
sfence, which exists on PIII, but lfence which is used for
readwritebarriers), and if Nathan or we find concurrency related
failures in some tests down the line, we will need to put locks in
that part of the code. Locks are a really expensive way to do this
type of serialization, but that's the only option.
Thanks,
Rana
On 4/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> On Friday 06 April 2007 02:39 Rana Dasgupta wrote:
> > On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> > > > On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > > > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > > > > I would like to see these modifications. I wonder what
> > > > > > > > > > > you've done in
> > > > > > > > >
> > > > > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > > > > vmcore/include/atomics.h. They contain mfence and sfence
> > > > > > > > > instructions in inline assembly which have to be changed to
> > > > > > > > > something else on P3.
> > > > > >
> > > > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > > > > > strongly ordered for writes ?
> > > > >
> > > > > What about MemoryReadWriteBarrier()? If you know, what kind of code
> > > > > should be used for this in P3?
> > > >
> > > > One of the compiler guys can confirm this. But I don't believe that
> > > > you need to worry about any of the fence instructions fence on any of
> > > > the PIII, PIV genuine intel procs unless you are using streaming mode
> > > > ( SIMD ) instructions which are weakly ordered.
> > >
> > > I actually grepped the use for MemoryReadWriteBarrier, MemoryWriteBarrier
> > > and apr_memory_rw_barrier functions which are wrappers to mfence/sfence
> > > instructions. They aren't used in the code which uses SSE2 in any way.
> > >
> > > - The apr_memory_rw_barrier (executes mfence) function is used in thin
> > > locks implementation in threading code.
> > >
> > > - MemoryReadWriteBarrier (executes mfence) is used in
> > > org.apache.harmony.util.concurrent natives implementation after
> > > writing/reading int/long/object fields via JNI.
> > >
> > > - MemoryWriteBarrier (executes sfence) is used in classloader for fast
> > > management of classes collection and in strings pool for the same reason.
> > >
> > > In all three cases SSE2 is not involved in any way, simply loads and
> > > stores are done with the memory. According to you in all of those cases
> > > memory barriers are not needed. I am just confused then why were they
> > > inserted in those places?
> >
> > I don't know the answer to this question ...unless it was intended to
> > cover clones etc. that don't fully support the writeback model...
>
> I should have put the question in a different way. I didn't actually mean that
> you should know why some code is written in VM. I don't know why some code is
> written in many places including those I mentioned.
>
> The question should actually be like, should we actually remove mfence and
> sfence assembly instructions from the VM sources for x86/x86_64 platforms? I
> commented mfence in port/src/thread/linux/apr_thread_ext.c and mfence/sfence
> in vmcore/include/atomics.h and ran VM tests on 5 different SMP boxes with no
> less than 4 logical CPUs on each of them (2 win32, linux32, windows64 and
> linux64). Tests seem to work just fine without mfence and sfence in VM code.
>
> With these instructions removed from the code there shall be no problem with
> P3 port on VM side. It seems they are actually unnecessary and were inserted
> for a reason that they help on SMP to synchronize caches. After your
> explanation that they are actually needed only when SSE2 is involved, it
> seems (and my tests show this) that they are just not needed.
>
> --
> Gregory
>
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
On 4/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> On Friday 06 April 2007 02:39 Rana Dasgupta wrote:
> > On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> > > > On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > > > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > > > > I would like to see these modifications. I wonder what
> > > > > > > > > > > you've done in
> > > > > > > > >
> > > > > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > > > > vmcore/include/atomics.h. They contain mfence and sfence
> > > > > > > > > instructions in inline assembly which have to be changed to
> > > > > > > > > something else on P3.
> > > > > >
> > > > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > > > > > strongly ordered for writes ?
> > > > >
> > > > > What about MemoryReadWriteBarrier()? If you know, what kind of code
> > > > > should be used for this in P3?
> > > >
> > > > One of the compiler guys can confirm this. But I don't believe that
> > > > you need to worry about any of the fence instructions fence on any of
> > > > the PIII, PIV genuine intel procs unless you are using streaming mode
> > > > ( SIMD ) instructions which are weakly ordered.
> > >
> > > I actually grepped the use for MemoryReadWriteBarrier, MemoryWriteBarrier
> > > and apr_memory_rw_barrier functions which are wrappers to mfence/sfence
> > > instructions. They aren't used in the code which uses SSE2 in any way.
> > >
> > > - The apr_memory_rw_barrier (executes mfence) function is used in thin
> > > locks implementation in threading code.
> > >
> > > - MemoryReadWriteBarrier (executes mfence) is used in
> > > org.apache.harmony.util.concurrent natives implementation after
> > > writing/reading int/long/object fields via JNI.
> > >
> > > - MemoryWriteBarrier (executes sfence) is used in classloader for fast
> > > management of classes collection and in strings pool for the same reason.
> > >
> > > In all three cases SSE2 is not involved in any way, simply loads and
> > > stores are done with the memory. According to you in all of those cases
> > > memory barriers are not needed. I am just confused then why were they
> > > inserted in those places?
> >
> > I don't know the answer to this question ...unless it was intended to
> > cover clones etc. that don't fully support the writeback model...
>
> I should have put the question in a different way. I didn't actually mean that
> you should know why some code is written in VM. I don't know why some code is
> written in many places including those I mentioned.
>
> The question should actually be like, should we actually remove mfence and
> sfence assembly instructions from the VM sources for x86/x86_64 platforms? I
> commented mfence in port/src/thread/linux/apr_thread_ext.c and mfence/sfence
> in vmcore/include/atomics.h and ran VM tests on 5 different SMP boxes with no
> less than 4 logical CPUs on each of them (2 win32, linux32, windows64 and
> linux64). Tests seem to work just fine without mfence and sfence in VM code.
>
> With these instructions removed from the code there shall be no problem with
> P3 port on VM side. It seems they are actually unnecessary and were inserted
> for a reason that they help on SMP to synchronize caches. After your
> explanation that they are actually needed only when SSE2 is involved, it
> seems (and my tests show this) that they are just not needed.
>
> --
> Gregory
>
Well, we all know that executing incorrect concurrency code and not
seeing any errors or side-effects isn't a guarantee of correctness,
but the anecdotal evidence is compelling.
What was the change you made specifically? Did you also remove the
other barrier calls that were used in some cases for 64-bit platforms?
If there's any methods that are NOT being used and not a part of a
required API, then we should definitely eliminate those as it's just
cruft. As for those bits of code that are in the execution path, does
anyone know why the code was originally introduced and what the need
was? This would've been a great place for some code comments. :(
-Nathan
Re: [general] What platforms do we support?
Posted by Gregory Shimansky <gs...@gmail.com>.
On Friday 06 April 2007 02:39 Rana Dasgupta wrote:
> On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> > > On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > > > I would like to see these modifications. I wonder what
> > > > > > > > > > you've done in
> > > > > > > >
> > > > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > > > vmcore/include/atomics.h. They contain mfence and sfence
> > > > > > > > instructions in inline assembly which have to be changed to
> > > > > > > > something else on P3.
> > > > >
> > > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > > > > strongly ordered for writes ?
> > > >
> > > > What about MemoryReadWriteBarrier()? If you know, what kind of code
> > > > should be used for this in P3?
> > >
> > > One of the compiler guys can confirm this. But I don't believe that
> > > you need to worry about any of the fence instructions fence on any of
> > > the PIII, PIV genuine intel procs unless you are using streaming mode
> > > ( SIMD ) instructions which are weakly ordered.
> >
> > I actually grepped the use for MemoryReadWriteBarrier, MemoryWriteBarrier
> > and apr_memory_rw_barrier functions which are wrappers to mfence/sfence
> > instructions. They aren't used in the code which uses SSE2 in any way.
> >
> > - The apr_memory_rw_barrier (executes mfence) function is used in thin
> > locks implementation in threading code.
> >
> > - MemoryReadWriteBarrier (executes mfence) is used in
> > org.apache.harmony.util.concurrent natives implementation after
> > writing/reading int/long/object fields via JNI.
> >
> > - MemoryWriteBarrier (executes sfence) is used in classloader for fast
> > management of classes collection and in strings pool for the same reason.
> >
> > In all three cases SSE2 is not involved in any way, simply loads and
> > stores are done with the memory. According to you in all of those cases
> > memory barriers are not needed. I am just confused then why were they
> > inserted in those places?
>
> I don't know the answer to this question ...unless it was intended to
> cover clones etc. that don't fully support the writeback model...
I should have put the question in a different way. I didn't actually mean that
you should know why some code is written in VM. I don't know why some code is
written in many places including those I mentioned.
The question should actually be like, should we actually remove mfence and
sfence assembly instructions from the VM sources for x86/x86_64 platforms? I
commented mfence in port/src/thread/linux/apr_thread_ext.c and mfence/sfence
in vmcore/include/atomics.h and ran VM tests on 5 different SMP boxes with no
less than 4 logical CPUs on each of them (2 win32, linux32, windows64 and
linux64). Tests seem to work just fine without mfence and sfence in VM code.
With these instructions removed from the code there shall be no problem with
P3 port on VM side. It seems they are actually unnecessary and were inserted
for a reason that they help on SMP to synchronize caches. After your
explanation that they are actually needed only when SSE2 is involved, it
seems (and my tests show this) that they are just not needed.
--
Gregory
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> > On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > > I would like to see these modifications. I wonder what you've
> > > > > > > > > done in
> > > > > > >
> > > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > > vmcore/include/atomics.h. They contain mfence and sfence
> > > > > > > instructions in inline assembly which have to be changed to
> > > > > > > something else on P3.
> > > >
> > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > > > strongly ordered for writes ?
> > >
> > > What about MemoryReadWriteBarrier()? If you know, what kind of code
> > > should be used for this in P3?
> >
> > One of the compiler guys can confirm this. But I don't believe that
> > you need to worry about any of the fence instructions fence on any of
> > the PIII, PIV genuine intel procs unless you are using streaming mode
> > ( SIMD ) instructions which are weakly ordered.
>
> I actually grepped the use for MemoryReadWriteBarrier, MemoryWriteBarrier and
> apr_memory_rw_barrier functions which are wrappers to mfence/sfence
> instructions. They aren't used in the code which uses SSE2 in any way.
>
> - The apr_memory_rw_barrier (executes mfence) function is used in thin locks
> implementation in threading code.
>
> - MemoryReadWriteBarrier (executes mfence) is used in
> org.apache.harmony.util.concurrent natives implementation after
> writing/reading int/long/object fields via JNI.
>
> - MemoryWriteBarrier (executes sfence) is used in classloader for fast
> management of classes collection and in strings pool for the same reason.
>
> In all three cases SSE2 is not involved in any way, simply loads and stores
> are done with the memory. According to you in all of those cases memory
> barriers are not needed. I am just confused then why were they inserted in
> those places?
I don't know the answer to this question ...unless it was intended to
cover clones etc. that don't fully support the writeback model...
>
> --
> Gregory
>
Re: [general] What platforms do we support?
Posted by Gregory Shimansky <gs...@gmail.com>.
On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > I would like to see these modifications. I wonder what you've
> > > > > > > > done in
> > > > > >
> > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > vmcore/include/atomics.h. They contain mfence and sfence
> > > > > > instructions in inline assembly which have to be changed to
> > > > > > something else on P3.
> > >
> > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > > strongly ordered for writes ?
> >
> > What about MemoryReadWriteBarrier()? If you know, what kind of code
> > should be used for this in P3?
>
> One of the compiler guys can confirm this. But I don't believe that
> you need to worry about any of the fence instructions fence on any of
> the PIII, PIV genuine intel procs unless you are using streaming mode
> ( SIMD ) instructions which are weakly ordered.
I actually grepped the use for MemoryReadWriteBarrier, MemoryWriteBarrier and
apr_memory_rw_barrier functions which are wrappers to mfence/sfence
instructions. They aren't used in the code which uses SSE2 in any way.
- The apr_memory_rw_barrier (executes mfence) function is used in thin locks
implementation in threading code.
- MemoryReadWriteBarrier (executes mfence) is used in
org.apache.harmony.util.concurrent natives implementation after
writing/reading int/long/object fields via JNI.
- MemoryWriteBarrier (executes sfence) is used in classloader for fast
management of classes collection and in strings pool for the same reason.
In all three cases SSE2 is not involved in any way, simply loads and stores
are done with the memory. According to you in all of those cases memory
barriers are not needed. I am just confused then why were they inserted in
those places?
--
Gregory
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
On 4/5/07, Rana Dasgupta <rd...@gmail.com> wrote:
> On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > On Thursday 05 April 2007 02:25 Nathan Beyer wrote:
> > > Yes, I believe what we want to say is code to the lowest common
> > > instruction set for static code in the VM, at least for each distinct
> > > instruction set (x86 32-bit, IPF, etc). For the x86 32-bit, the
> > > available instructions must be available in at least a P3.
> >
> > I don't quite understand why code patching doesn't help here? Classlib hythr
> > code does code patching to remove lock prefixes for some instructions (see
> > files in modules/portlib/src/main/native/thread/windows/windows.x86 and
> > modules/portlib/src/main/native/common/windows/lock386.c) on uniprocessors,
> > same could be done to patch away mfence and sfence.
> >
> >
>
> Technically, there is no reason why it cannot be dynamically patched
> as you describe. But if tomorrow there is a new helper that uses a
> fast platform library for memcpy that uses some SSE2 ( as eg., AMD
> fast memcpy does ) you will need to patch that too. If we want to
> support PIII, probably the simplest way is to restrict ourselves to
> the PIII instruction set and only let the jit detect platform and
> generate more advanced instruction sequences. There is no perf etc.
> loss in this because in any case, we want the applications to spend
> almost all their time in jitted code.
>
This would be the approach I think is most appropriate. We want to
minimize the static native code anyway. Additionally, just coding to
the lowest common instruction set would keep the code much cleaner and
easier to maintain.
-Nathan
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
On 4/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> On Thursday 05 April 2007 02:25 Nathan Beyer wrote:
> > Yes, I believe what we want to say is code to the lowest common
> > instruction set for static code in the VM, at least for each distinct
> > instruction set (x86 32-bit, IPF, etc). For the x86 32-bit, the
> > available instructions must be available in at least a P3.
>
> I don't quite understand why code patching doesn't help here? Classlib hythr
> code does code patching to remove lock prefixes for some instructions (see
> files in modules/portlib/src/main/native/thread/windows/windows.x86 and
> modules/portlib/src/main/native/common/windows/lock386.c) on uniprocessors,
> same could be done to patch away mfence and sfence.
>
>
Technically, there is no reason why it cannot be dynamically patched
as you describe. But if tomorrow there is a new helper that uses a
fast platform library for memcpy that uses some SSE2 ( as eg., AMD
fast memcpy does ) you will need to patch that too. If we want to
support PIII, probably the simplest way is to restrict ourselves to
the PIII instruction set and only let the jit detect platform and
generate more advanced instruction sequences. There is no perf etc.
loss in this because in any case, we want the applications to spend
almost all their time in jitted code.
Re: [general] What platforms do we support?
Posted by Gregory Shimansky <gs...@gmail.com>.
On Thursday 05 April 2007 02:25 Nathan Beyer wrote:
> On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > > I would like to see these modifications. I wonder what you've
> > > > > > > > done in
> > > > > >
> > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > vmcore/include/atomics.h. They contain mfence and sfence
> > > > > > instructions in inline assembly which have to be changed to
> > > > > > something else on P3.
> > >
> > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > > strongly ordered for writes ?
> >
> > What about MemoryReadWriteBarrier()? If you know, what kind of code
> > should be used for this in P3?
> >
> > > > > Can we produce separate binary build for P3 if it is not easy to
> > > > > replace mfence/sfence?
> > > >
> > > > Jitrino can use runtime detection of CPU features supported and emit
> > > > appropriate code.
> > > > Can we do the same with VM (check flag) to avoid multiple
> > > > distributions?
> > >
> > > Jitrino generates code late, the VM doesn't. So I am not sure how this
> > > would work unless we link all versions of the asm's and then decide
> > > which ones to call at runtime, which has a cost. My suggestion would
> > > be that if we want the x86-32 bits to be PIII compatible, we should
> > > only use PIII instructions ( upto SSE ) in all the static 32 bit
> > > binaries. The jit can choose to generate more advanced instruction
> > > sequences at runtime based on cpuid if the paltform supports it.
> >
> > I am not sure what you mean by using only P3 compatible code in all
> > statically linked binaries. In this case what should be used for
> > MemoryWriteBarrier function so that it would work on P4 too?
>
> Yes, I believe what we want to say is code to the lowest common
> instruction set for static code in the VM, at least for each distinct
> instruction set (x86 32-bit, IPF, etc). For the x86 32-bit, the
> available instructions must be available in at least a P3.
I don't quite understand why code patching doesn't help here? Classlib hythr
code does code patching to remove lock prefixes for some instructions (see
files in modules/portlib/src/main/native/thread/windows/windows.x86 and
modules/portlib/src/main/native/common/windows/lock386.c) on uniprocessors,
same could be done to patch away mfence and sfence.
> > What about code patching upon initialization? The [m|s]fence instructions
> > could be replaced with NOPs or other code for P3 by the initialization
> > code. Of course this would prevent inlining of these functions so that
> > all places where code has to be patched are known, but it should be
> > faster than choosing the appropriate barrier function implementation at
> > runtime. Also care should be taken for [lib]hythr library which uses
> > apr_memory_rw_barrier function, it should be patched as well after
> > [lib]hythr is loaded, possibly by the library initialization code since
> > it is currently loaded before harmonyvm by the launcher as a hyport
> > dependency.
> >
> > --
> > Gregory
--
Gregory
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > I would like to see these modifications. I wonder what you've
> > > > > > > done in
> > > > >
> > > > > port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> > > > > They contain mfence and sfence instructions in inline assembly which
> > > > > have to be changed to something else on P3.
> >
> > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > strongly ordered for writes ?
>
> What about MemoryReadWriteBarrier()? If you know, what kind of code should be
> used for this in P3?
>
> > > > Can we produce separate binary build for P3 if it is not easy to
> > > > replace mfence/sfence?
> > >
> > > Jitrino can use runtime detection of CPU features supported and emit
> > > appropriate code.
> > > Can we do the same with VM (check flag) to avoid multiple distributions?
> >
> > Jitrino generates code late, the VM doesn't. So I am not sure how this
> > would work unless we link all versions of the asm's and then decide
> > which ones to call at runtime, which has a cost. My suggestion would
> > be that if we want the x86-32 bits to be PIII compatible, we should
> > only use PIII instructions ( upto SSE ) in all the static 32 bit
> > binaries. The jit can choose to generate more advanced instruction
> > sequences at runtime based on cpuid if the paltform supports it.
>
> I am not sure what you mean by using only P3 compatible code in all statically
> linked binaries. In this case what should be used for MemoryWriteBarrier
> function so that it would work on P4 too?
Yes, I believe what we want to say is code to the lowest common
instruction set for static code in the VM, at least for each distinct
instruction set (x86 32-bit, IPF, etc). For the x86 32-bit, the
available instructions must be available in at least a P3.
-Nathan
>
> What about code patching upon initialization? The [m|s]fence instructions
> could be replaced with NOPs or other code for P3 by the initialization code.
> Of course this would prevent inlining of these functions so that all places
> where code has to be patched are known, but it should be faster than choosing
> the appropriate barrier function implementation at runtime. Also care should
> be taken for [lib]hythr library which uses apr_memory_rw_barrier function, it
> should be patched as well after [lib]hythr is loaded, possibly by the library
> initialization code since it is currently loaded before harmonyvm by the
> launcher as a hyport dependency.
>
> --
> Gregory
>
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
On 4/4/07, Gregory Shimansky <gs...@gmail.com> wrote:
> On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > > I would like to see these modifications. I wonder what you've
> > > > > > > done in
> > > > >
> > > > > port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> > > > > They contain mfence and sfence instructions in inline assembly which
> > > > > have to be changed to something else on P3.
> >
> > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > strongly ordered for writes ?
>
> What about MemoryReadWriteBarrier()? If you know, what kind of code should be
> used for this in P3?
One of the compiler guys can confirm this. But I don't believe that
you need to worry about any of the fence instructions fence on any of
the PIII, PIV genuine intel procs unless you are using streaming mode
( SIMD ) instructions which are weakly ordered.
>
> --
> Gregory
>
Re: [general] What platforms do we support?
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> > > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > > I would like to see these modifications. I wonder what you've
> > > > > > done in
> > > >
> > > > port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> > > > They contain mfence and sfence instructions in inline assembly which
> > > > have to be changed to something else on P3.
>
> MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> strongly ordered for writes ?
What about MemoryReadWriteBarrier()? If you know, what kind of code should be
used for this in P3?
> > > Can we produce separate binary build for P3 if it is not easy to
> > > replace mfence/sfence?
> >
> > Jitrino can use runtime detection of CPU features supported and emit
> > appropriate code.
> > Can we do the same with VM (check flag) to avoid multiple distributions?
>
> Jitrino generates code late, the VM doesn't. So I am not sure how this
> would work unless we link all versions of the asm's and then decide
> which ones to call at runtime, which has a cost. My suggestion would
> be that if we want the x86-32 bits to be PIII compatible, we should
> only use PIII instructions ( upto SSE ) in all the static 32 bit
> binaries. The jit can choose to generate more advanced instruction
> sequences at runtime based on cpuid if the paltform supports it.
I am not sure what you mean by using only P3 compatible code in all statically
linked binaries. In this case what should be used for MemoryWriteBarrier
function so that it would work on P4 too?
What about code patching upon initialization? The [m|s]fence instructions
could be replaced with NOPs or other code for P3 by the initialization code.
Of course this would prevent inlining of these functions so that all places
where code has to be patched are known, but it should be faster than choosing
the appropriate barrier function implementation at runtime. Also care should
be taken for [lib]hythr library which uses apr_memory_rw_barrier function, it
should be patched as well after [lib]hythr is loaded, possibly by the library
initialization code since it is currently loaded before harmonyvm by the
launcher as a hyport dependency.
--
Gregory
Re: [general] What platforms do we support?
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/5/07, Rana Dasgupta <rd...@gmail.com> wrote:
>
>
> Jitrino generates code late, the VM doesn't. So I am not sure how this
> would work unless we link all versions of the asm's and then decide
> which ones to call at runtime, which has a cost. My suggestion would
> be that if we want the x86-32 bits to be PIII compatible, we should
> only use PIII instructions ( upto SSE ) in all the static 32 bit
> binaries. The jit can choose to generate more advanced instruction
> sequences at runtime based on cpuid if the paltform supports it.
>
> Is runtime check really expensive in scenarios we have? Can all CPU
dependent code be moved into separate library, so a component can
decide in runtime which library to load
during startup and avoid further checks?
--
Mikhail Fursov
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
On 4/4/07, Mikhail Fursov <mi...@gmail.com> wrote:
> On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> >
> > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > > > I would like to see these modifications. I wonder what you've done in
> > > port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> > > They contain mfence and sfence instructions in inline assembly which
> > > have to be changed to something else on P3.
MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
strongly ordered for writes ?
> > Can we produce separate binary build for P3 if it is not easy to
> > replace mfence/sfence?
>
>
> Jitrino can use runtime detection of CPU features supported and emit
> appropriate code.
> Can we do the same with VM (check flag) to avoid multiple distributions?
>
Jitrino generates code late, the VM doesn't. So I am not sure how this
would work unless we link all versions of the asm's and then decide
which ones to call at runtime, which has a cost. My suggestion would
be that if we want the x86-32 bits to be PIII compatible, we should
only use PIII instructions ( upto SSE ) in all the static 32 bit
binaries. The jit can choose to generate more advanced instruction
sequences at runtime based on cpuid if the paltform supports it.
> --
> Mikhail Fursov
>
Re: [general] What platforms do we support?
Posted by Alexey Petrenko <al...@gmail.com>.
2007/4/4, Mikhail Fursov <mi...@gmail.com>:
> On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
> >
> > 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > > Evgueni Brevnov wrote:
> > > > Hi,
> > > >
> > > > Seems like this is not a technical discussion anyway I did some
> > > > expiriments on my Fedora Core release 5 (Bordeaux) PentiumIII
> > > > machine. Additionally to HARMONY-3246 it required a few modifications
> > > > in sources and proper arguments to the compiler to run HelloWord and
> > > > other applications. I can provide a patch with modifications to
> > > > building system to build PentiumIII friendly VM. Is anyone intrested
> > > > in this?
> > >
> > > I would like to see these modifications. I wonder what you've done in
> > > port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> > > They contain mfence and sfence instructions in inline assembly which
> > > have to be changed to something else on P3.
> > Can we produce separate binary build for P3 if it is not easy to
> > replace mfence/sfence?
> Jitrino can use runtime detection of CPU features supported and emit
> appropriate code.
Yep, it is better approach.
SY, Alexey
> Can we do the same with VM (check flag) to avoid multiple distributions?
>
> --
> Mikhail Fursov
>
Re: [general] What platforms do we support?
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/4/07, Alexey Petrenko <al...@gmail.com> wrote:
>
> 2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> > Evgueni Brevnov wrote:
> > > Hi,
> > >
> > > Seems like this is not a technical discussion anyway I did some
> > > expiriments on my Fedora Core release 5 (Bordeaux) PentiumIII
> > > machine. Additionally to HARMONY-3246 it required a few modifications
> > > in sources and proper arguments to the compiler to run HelloWord and
> > > other applications. I can provide a patch with modifications to
> > > building system to build PentiumIII friendly VM. Is anyone intrested
> > > in this?
> >
> > I would like to see these modifications. I wonder what you've done in
> > port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> > They contain mfence and sfence instructions in inline assembly which
> > have to be changed to something else on P3.
> Can we produce separate binary build for P3 if it is not easy to
> replace mfence/sfence?
Jitrino can use runtime detection of CPU features supported and emit
appropriate code.
Can we do the same with VM (check flag) to avoid multiple distributions?
--
Mikhail Fursov
Re: [general] What platforms do we support?
Posted by Alexey Petrenko <al...@gmail.com>.
2007/4/4, Gregory Shimansky <gs...@gmail.com>:
> Evgueni Brevnov wrote:
> > Hi,
> >
> > Seems like this is not a technical discussion anyway I did some
> > expiriments on my Fedora Core release 5 (Bordeaux) PentiumIII
> > machine. Additionally to HARMONY-3246 it required a few modifications
> > in sources and proper arguments to the compiler to run HelloWord and
> > other applications. I can provide a patch with modifications to
> > building system to build PentiumIII friendly VM. Is anyone intrested
> > in this?
>
> I would like to see these modifications. I wonder what you've done in
> port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> They contain mfence and sfence instructions in inline assembly which
> have to be changed to something else on P3.
Can we produce separate binary build for P3 if it is not easy to
replace mfence/sfence?
SY, Alexey
> > On 4/3/07, Mikhail Loenko <ml...@gmail.com> wrote:
> >> Fortunately we don't have to follow outcomes of those discussions
> >> when we work in Harmony :)
> >>
> >> Still we can ask the teams you referred to provide their feedback (if
> >> possible)
> >> to a wider audience
> >>
> >> As for the platforms some time ago Stepan said (and many people agreed
> >> to him)
> >> that most of the things that we currently fix are OS-independent, so
> >> we can focus
> >> on 32-bit architecture and not tie ourselves much to a specific platform
> >>
> >> Thanks,
> >> Mikhail
> >>
> >> 2007/4/3, Rana Dasgupta <rd...@gmail.com>:
> >> > Hi Xiao Feng,
> >> > You probably missed this, but we have taken an internal Intel
> >> > target to release Harmony first on Win32 in Q2 after a lot of
> >> > discussions in Judy's JCM meeting, based primarily on feedback from
> >> > the JIT and performance teams.
> >> >
> >> > Rana
> >> >
> >> > On 4/2/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> >> > > On 4/3/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> >> > > > On 4/3/07, Tim Ellison <t....@gmail.com> wrote:
> >> > > > >
> >> > > > > Nathan Beyer wrote:
> >> > > > > > However, from looking back on this mailing list thread, I
> >> couldn't
> >> > > > > > find any decision at the end of this or much of a consensus.
> >> I would
> >> > > > > > like to pull this together, vote on it. document it (site,
> >> Wiki, etc),
> >> > > > > > test it, etc.
> >> > > > >
> >> > > > > Agreed, let's try and get a consensus on what we will have in
> >> our M1
> >> > > > > build, and a date to shoot for it.
> >> > > > >
> >> > > > > I think we have a reasonable idea forming that it will be
> >> (taken from
> >> > > > > your list):
> >> > > > >
> >> > > > > - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> >> > > > > - IA64/IPF (Intel 64-bit architecture)
> >> > > > > - x86_64/AMD64/EMT64 (AMD architecture)
> >> > > > >
> >> > > > > - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> >> > > > > Windows 2003 R2, (Windows Vista?)
> >> > > > > - Linux; kernel v2.4.x, v2.6.x
> >> > > > > - (FreeBSD v???)
> >> > > > >
> >> > > > > I've put some in parentheses since we need to hear from people
> >> what work
> >> > > > > is required to get them ready and stable. I also removed the
> >> priority
> >> > > > > order since I think they are all equally important if we
> >> declare them
> >> > > > > stable.
> >> > > > >
> >> > > > > An M1 date of April 30th would give us a stable build ready for
> >> > > > > ApacheCon EU and JavaOne, which seems like a good goal. Working
> >> > > > > backwards we would then focus on stability for whatever we
> >> have got from
> >> > > > > April 23.
> >> > > > >
> >> > > > > I wonder if the Win2000 goal is possible in that timeframe?
> >> If not I
> >> > > > > suggest we live with WinXP as a minimum requirement for M1.
> >> Do we know
> >> > > > > what it takes to run on Vista/FreeBSD? Again I'm guessing
> >> non-trivial
> >> > > > > work remaining and we should drop it from M1 if so.
> >> > > > >
> >> > > > > Regards,
> >> > > > > Tim
> >> > > >
> >> > > >
> >> > > >
> >> > > > I think having a milestone we want to show a really fast and
> >> stable runtime
> >> > > > environment, not just another snapshot of what we have to the
> >> moment. If I'm
> >> > > > correct than 1 week between the feature freeze and release date
> >> is not
> >> > > > enough. Working on JIT I see ~30 JIRA issues that may affect real
> >> > > > applications, and running recently contributed test suites will
> >> reveal
> >> > > > more. I think we should strive to fix most of them before the
> >> milestone,
> >> > > > probably by the cost of limiting number of supported platforms.
> >> Then we may
> >> > > > go to the next milestone, including more platforms/configurations.
> >> > > >
> >> > > >
> >> > > >
> >> > > > Having this in mind I propose to release M1 with IA32 support
> >> only, may be
> >> > > > even limiting this support to Windows. Let's fix all stability
> >> problems
> >> > > > there and then go to the next milestone shortly, including
> >> support for Linux
> >> > > > or x86_64. I propose a feature freeze date of 15th of May and
> >> put M1 release
> >> > > > date of 15th of June. At the feature freeze we should complete
> >> current
> >> > > > development works and move on to stability to release a really
> >> mature
> >> > > > runtime. We might have release an "release candidate" before the
> >> JavaOne
> >> > > > which will have all the capabilities than our milestone build
> >> but without
> >> > > > all stability issues fixed.
> >> > > >
> >> > > >
> >> > > >
> >> > > > I also have comments about configurations:
> >> > > >
> >> > > > *- IA32/x86 with a minimum of P3 (SSE, not SSE2)*
> >> > > > **
> >> > > > **
> >> > > >
> >> > > > SSE+SSE2 unless someone commits to test and complete on pure PIII.
> >> > > > *- IA64/IPF (Intel 64-bit architecture)*
> >> > > >
> >> > > > DRLVM is poorly tested on IPF yet. This is rather for M3 milestone.
> >> > > >
> >> > > > *- x86_64/AMD64/EMT64 (AMD architecture)*
> >> > > > Let's put this aside for the first release. We have some
> >> stability level
> >> > > > there which is supported by CruiseControl and no regression on
> >> these
> >> > > > platform is enough for the first release. I'm fine to include
> >> this into M1
> >> > > > if someone commit to this.
> >> > > >
> >> > > > *- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> >> > > > Windows 2003 R2, (Windows Vista?)*
> >> > > >
> >> > > >
> >> > > >
> >> > > > + 1 for Windows 2003, Windows XP. It's interesting to try on
> >> Vista but I'd
> >> > > > give it some time to "grow up" before we go there.
> >> > >
> >> > > Pavel, I personally would vote Linux32 for the first release. If
> >> Win32
> >> > > is easier to achieve, we probably can make is an internal
> >> > > (intermediate) milestone for the real Linux32 release. (Actually I
> >> > > don't know if Win32 is easier than Linux32).
> >> > >
> >> > > Thanks,
> >> > > xiaofeng
> >> > >
> >> > > >
> >> > > > *- Linux; kernel v2.4.x, v2.6.x*
> >> > > >
> >> > > >
> >> > > >
> >> > > > I'm sure Geir will vote for Linux, but I'm reluctant to put
> >> everything in
> >> > > > the first milestone.
> >> > > >
> >> > > >
> >> > > > *- (FreeBSD v???)
> >> > > > *
> >> > > >
> >> > > > Volunteers? ;-)
> >> > > >
> >> > > >
> >> > > >
> >> > > > Thank you,
> >> > > >
> >> > > > Pavel Ozhdikhin
> >> > > >
> >> > > > Intel Managed Runtime Division
> >> > > >
> >> > >
> >> >
> >>
> >
>
>
> --
> Gregory
>
>
Re: [general] What platforms do we support?
Posted by Gregory Shimansky <gs...@gmail.com>.
Evgueni Brevnov wrote:
> Hi,
>
> Seems like this is not a technical discussion anyway I did some
> expiriments on my Fedora Core release 5 (Bordeaux) PentiumIII
> machine. Additionally to HARMONY-3246 it required a few modifications
> in sources and proper arguments to the compiler to run HelloWord and
> other applications. I can provide a patch with modifications to
> building system to build PentiumIII friendly VM. Is anyone intrested
> in this?
I would like to see these modifications. I wonder what you've done in
port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
They contain mfence and sfence instructions in inline assembly which
have to be changed to something else on P3.
> On 4/3/07, Mikhail Loenko <ml...@gmail.com> wrote:
>> Fortunately we don't have to follow outcomes of those discussions
>> when we work in Harmony :)
>>
>> Still we can ask the teams you referred to provide their feedback (if
>> possible)
>> to a wider audience
>>
>> As for the platforms some time ago Stepan said (and many people agreed
>> to him)
>> that most of the things that we currently fix are OS-independent, so
>> we can focus
>> on 32-bit architecture and not tie ourselves much to a specific platform
>>
>> Thanks,
>> Mikhail
>>
>> 2007/4/3, Rana Dasgupta <rd...@gmail.com>:
>> > Hi Xiao Feng,
>> > You probably missed this, but we have taken an internal Intel
>> > target to release Harmony first on Win32 in Q2 after a lot of
>> > discussions in Judy's JCM meeting, based primarily on feedback from
>> > the JIT and performance teams.
>> >
>> > Rana
>> >
>> > On 4/2/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>> > > On 4/3/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
>> > > > On 4/3/07, Tim Ellison <t....@gmail.com> wrote:
>> > > > >
>> > > > > Nathan Beyer wrote:
>> > > > > > However, from looking back on this mailing list thread, I
>> couldn't
>> > > > > > find any decision at the end of this or much of a consensus.
>> I would
>> > > > > > like to pull this together, vote on it. document it (site,
>> Wiki, etc),
>> > > > > > test it, etc.
>> > > > >
>> > > > > Agreed, let's try and get a consensus on what we will have in
>> our M1
>> > > > > build, and a date to shoot for it.
>> > > > >
>> > > > > I think we have a reasonable idea forming that it will be
>> (taken from
>> > > > > your list):
>> > > > >
>> > > > > - IA32/x86 with a minimum of P3 (SSE, not SSE2)
>> > > > > - IA64/IPF (Intel 64-bit architecture)
>> > > > > - x86_64/AMD64/EMT64 (AMD architecture)
>> > > > >
>> > > > > - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
>> > > > > Windows 2003 R2, (Windows Vista?)
>> > > > > - Linux; kernel v2.4.x, v2.6.x
>> > > > > - (FreeBSD v???)
>> > > > >
>> > > > > I've put some in parentheses since we need to hear from people
>> what work
>> > > > > is required to get them ready and stable. I also removed the
>> priority
>> > > > > order since I think they are all equally important if we
>> declare them
>> > > > > stable.
>> > > > >
>> > > > > An M1 date of April 30th would give us a stable build ready for
>> > > > > ApacheCon EU and JavaOne, which seems like a good goal. Working
>> > > > > backwards we would then focus on stability for whatever we
>> have got from
>> > > > > April 23.
>> > > > >
>> > > > > I wonder if the Win2000 goal is possible in that timeframe?
>> If not I
>> > > > > suggest we live with WinXP as a minimum requirement for M1.
>> Do we know
>> > > > > what it takes to run on Vista/FreeBSD? Again I'm guessing
>> non-trivial
>> > > > > work remaining and we should drop it from M1 if so.
>> > > > >
>> > > > > Regards,
>> > > > > Tim
>> > > >
>> > > >
>> > > >
>> > > > I think having a milestone we want to show a really fast and
>> stable runtime
>> > > > environment, not just another snapshot of what we have to the
>> moment. If I'm
>> > > > correct than 1 week between the feature freeze and release date
>> is not
>> > > > enough. Working on JIT I see ~30 JIRA issues that may affect real
>> > > > applications, and running recently contributed test suites will
>> reveal
>> > > > more. I think we should strive to fix most of them before the
>> milestone,
>> > > > probably by the cost of limiting number of supported platforms.
>> Then we may
>> > > > go to the next milestone, including more platforms/configurations.
>> > > >
>> > > >
>> > > >
>> > > > Having this in mind I propose to release M1 with IA32 support
>> only, may be
>> > > > even limiting this support to Windows. Let's fix all stability
>> problems
>> > > > there and then go to the next milestone shortly, including
>> support for Linux
>> > > > or x86_64. I propose a feature freeze date of 15th of May and
>> put M1 release
>> > > > date of 15th of June. At the feature freeze we should complete
>> current
>> > > > development works and move on to stability to release a really
>> mature
>> > > > runtime. We might have release an "release candidate" before the
>> JavaOne
>> > > > which will have all the capabilities than our milestone build
>> but without
>> > > > all stability issues fixed.
>> > > >
>> > > >
>> > > >
>> > > > I also have comments about configurations:
>> > > >
>> > > > *- IA32/x86 with a minimum of P3 (SSE, not SSE2)*
>> > > > **
>> > > > **
>> > > >
>> > > > SSE+SSE2 unless someone commits to test and complete on pure PIII.
>> > > > *- IA64/IPF (Intel 64-bit architecture)*
>> > > >
>> > > > DRLVM is poorly tested on IPF yet. This is rather for M3 milestone.
>> > > >
>> > > > *- x86_64/AMD64/EMT64 (AMD architecture)*
>> > > > Let's put this aside for the first release. We have some
>> stability level
>> > > > there which is supported by CruiseControl and no regression on
>> these
>> > > > platform is enough for the first release. I'm fine to include
>> this into M1
>> > > > if someone commit to this.
>> > > >
>> > > > *- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
>> > > > Windows 2003 R2, (Windows Vista?)*
>> > > >
>> > > >
>> > > >
>> > > > + 1 for Windows 2003, Windows XP. It's interesting to try on
>> Vista but I'd
>> > > > give it some time to "grow up" before we go there.
>> > >
>> > > Pavel, I personally would vote Linux32 for the first release. If
>> Win32
>> > > is easier to achieve, we probably can make is an internal
>> > > (intermediate) milestone for the real Linux32 release. (Actually I
>> > > don't know if Win32 is easier than Linux32).
>> > >
>> > > Thanks,
>> > > xiaofeng
>> > >
>> > > >
>> > > > *- Linux; kernel v2.4.x, v2.6.x*
>> > > >
>> > > >
>> > > >
>> > > > I'm sure Geir will vote for Linux, but I'm reluctant to put
>> everything in
>> > > > the first milestone.
>> > > >
>> > > >
>> > > > *- (FreeBSD v???)
>> > > > *
>> > > >
>> > > > Volunteers? ;-)
>> > > >
>> > > >
>> > > >
>> > > > Thank you,
>> > > >
>> > > > Pavel Ozhdikhin
>> > > >
>> > > > Intel Managed Runtime Division
>> > > >
>> > >
>> >
>>
>
--
Gregory
Re: [general] What platforms do we support?
Posted by Evgueni Brevnov <ev...@gmail.com>.
Hi,
Seems like this is not a technical discussion anyway I did some
expiriments on my Fedora Core release 5 (Bordeaux) PentiumIII
machine. Additionally to HARMONY-3246 it required a few modifications
in sources and proper arguments to the compiler to run HelloWord and
other applications. I can provide a patch with modifications to
building system to build PentiumIII friendly VM. Is anyone intrested
in this?
Evgueni.
On 4/3/07, Mikhail Loenko <ml...@gmail.com> wrote:
> Fortunately we don't have to follow outcomes of those discussions
> when we work in Harmony :)
>
> Still we can ask the teams you referred to provide their feedback (if possible)
> to a wider audience
>
> As for the platforms some time ago Stepan said (and many people agreed to him)
> that most of the things that we currently fix are OS-independent, so
> we can focus
> on 32-bit architecture and not tie ourselves much to a specific platform
>
> Thanks,
> Mikhail
>
> 2007/4/3, Rana Dasgupta <rd...@gmail.com>:
> > Hi Xiao Feng,
> > You probably missed this, but we have taken an internal Intel
> > target to release Harmony first on Win32 in Q2 after a lot of
> > discussions in Judy's JCM meeting, based primarily on feedback from
> > the JIT and performance teams.
> >
> > Rana
> >
> > On 4/2/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > On 4/3/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > > > On 4/3/07, Tim Ellison <t....@gmail.com> wrote:
> > > > >
> > > > > Nathan Beyer wrote:
> > > > > > However, from looking back on this mailing list thread, I couldn't
> > > > > > find any decision at the end of this or much of a consensus. I would
> > > > > > like to pull this together, vote on it. document it (site, Wiki, etc),
> > > > > > test it, etc.
> > > > >
> > > > > Agreed, let's try and get a consensus on what we will have in our M1
> > > > > build, and a date to shoot for it.
> > > > >
> > > > > I think we have a reasonable idea forming that it will be (taken from
> > > > > your list):
> > > > >
> > > > > - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> > > > > - IA64/IPF (Intel 64-bit architecture)
> > > > > - x86_64/AMD64/EMT64 (AMD architecture)
> > > > >
> > > > > - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > > > > Windows 2003 R2, (Windows Vista?)
> > > > > - Linux; kernel v2.4.x, v2.6.x
> > > > > - (FreeBSD v???)
> > > > >
> > > > > I've put some in parentheses since we need to hear from people what work
> > > > > is required to get them ready and stable. I also removed the priority
> > > > > order since I think they are all equally important if we declare them
> > > > > stable.
> > > > >
> > > > > An M1 date of April 30th would give us a stable build ready for
> > > > > ApacheCon EU and JavaOne, which seems like a good goal. Working
> > > > > backwards we would then focus on stability for whatever we have got from
> > > > > April 23.
> > > > >
> > > > > I wonder if the Win2000 goal is possible in that timeframe? If not I
> > > > > suggest we live with WinXP as a minimum requirement for M1. Do we know
> > > > > what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
> > > > > work remaining and we should drop it from M1 if so.
> > > > >
> > > > > Regards,
> > > > > Tim
> > > >
> > > >
> > > >
> > > > I think having a milestone we want to show a really fast and stable runtime
> > > > environment, not just another snapshot of what we have to the moment. If I'm
> > > > correct than 1 week between the feature freeze and release date is not
> > > > enough. Working on JIT I see ~30 JIRA issues that may affect real
> > > > applications, and running recently contributed test suites will reveal
> > > > more. I think we should strive to fix most of them before the milestone,
> > > > probably by the cost of limiting number of supported platforms. Then we may
> > > > go to the next milestone, including more platforms/configurations.
> > > >
> > > >
> > > >
> > > > Having this in mind I propose to release M1 with IA32 support only, may be
> > > > even limiting this support to Windows. Let's fix all stability problems
> > > > there and then go to the next milestone shortly, including support for Linux
> > > > or x86_64. I propose a feature freeze date of 15th of May and put M1 release
> > > > date of 15th of June. At the feature freeze we should complete current
> > > > development works and move on to stability to release a really mature
> > > > runtime. We might have release an "release candidate" before the JavaOne
> > > > which will have all the capabilities than our milestone build but without
> > > > all stability issues fixed.
> > > >
> > > >
> > > >
> > > > I also have comments about configurations:
> > > >
> > > > *- IA32/x86 with a minimum of P3 (SSE, not SSE2)*
> > > > **
> > > > **
> > > >
> > > > SSE+SSE2 unless someone commits to test and complete on pure PIII.
> > > > *- IA64/IPF (Intel 64-bit architecture)*
> > > >
> > > > DRLVM is poorly tested on IPF yet. This is rather for M3 milestone.
> > > >
> > > > *- x86_64/AMD64/EMT64 (AMD architecture)*
> > > > Let's put this aside for the first release. We have some stability level
> > > > there which is supported by CruiseControl and no regression on these
> > > > platform is enough for the first release. I'm fine to include this into M1
> > > > if someone commit to this.
> > > >
> > > > *- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > > > Windows 2003 R2, (Windows Vista?)*
> > > >
> > > >
> > > >
> > > > + 1 for Windows 2003, Windows XP. It's interesting to try on Vista but I'd
> > > > give it some time to "grow up" before we go there.
> > >
> > > Pavel, I personally would vote Linux32 for the first release. If Win32
> > > is easier to achieve, we probably can make is an internal
> > > (intermediate) milestone for the real Linux32 release. (Actually I
> > > don't know if Win32 is easier than Linux32).
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > > >
> > > > *- Linux; kernel v2.4.x, v2.6.x*
> > > >
> > > >
> > > >
> > > > I'm sure Geir will vote for Linux, but I'm reluctant to put everything in
> > > > the first milestone.
> > > >
> > > >
> > > > *- (FreeBSD v???)
> > > > *
> > > >
> > > > Volunteers? ;-)
> > > >
> > > >
> > > >
> > > > Thank you,
> > > >
> > > > Pavel Ozhdikhin
> > > >
> > > > Intel Managed Runtime Division
> > > >
> > >
> >
>
Re: [general] What platforms do we support?
Posted by Mikhail Loenko <ml...@gmail.com>.
Fortunately we don't have to follow outcomes of those discussions
when we work in Harmony :)
Still we can ask the teams you referred to provide their feedback (if possible)
to a wider audience
As for the platforms some time ago Stepan said (and many people agreed to him)
that most of the things that we currently fix are OS-independent, so
we can focus
on 32-bit architecture and not tie ourselves much to a specific platform
Thanks,
Mikhail
2007/4/3, Rana Dasgupta <rd...@gmail.com>:
> Hi Xiao Feng,
> You probably missed this, but we have taken an internal Intel
> target to release Harmony first on Win32 in Q2 after a lot of
> discussions in Judy's JCM meeting, based primarily on feedback from
> the JIT and performance teams.
>
> Rana
>
> On 4/2/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > On 4/3/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > > On 4/3/07, Tim Ellison <t....@gmail.com> wrote:
> > > >
> > > > Nathan Beyer wrote:
> > > > > However, from looking back on this mailing list thread, I couldn't
> > > > > find any decision at the end of this or much of a consensus. I would
> > > > > like to pull this together, vote on it. document it (site, Wiki, etc),
> > > > > test it, etc.
> > > >
> > > > Agreed, let's try and get a consensus on what we will have in our M1
> > > > build, and a date to shoot for it.
> > > >
> > > > I think we have a reasonable idea forming that it will be (taken from
> > > > your list):
> > > >
> > > > - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> > > > - IA64/IPF (Intel 64-bit architecture)
> > > > - x86_64/AMD64/EMT64 (AMD architecture)
> > > >
> > > > - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > > > Windows 2003 R2, (Windows Vista?)
> > > > - Linux; kernel v2.4.x, v2.6.x
> > > > - (FreeBSD v???)
> > > >
> > > > I've put some in parentheses since we need to hear from people what work
> > > > is required to get them ready and stable. I also removed the priority
> > > > order since I think they are all equally important if we declare them
> > > > stable.
> > > >
> > > > An M1 date of April 30th would give us a stable build ready for
> > > > ApacheCon EU and JavaOne, which seems like a good goal. Working
> > > > backwards we would then focus on stability for whatever we have got from
> > > > April 23.
> > > >
> > > > I wonder if the Win2000 goal is possible in that timeframe? If not I
> > > > suggest we live with WinXP as a minimum requirement for M1. Do we know
> > > > what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
> > > > work remaining and we should drop it from M1 if so.
> > > >
> > > > Regards,
> > > > Tim
> > >
> > >
> > >
> > > I think having a milestone we want to show a really fast and stable runtime
> > > environment, not just another snapshot of what we have to the moment. If I'm
> > > correct than 1 week between the feature freeze and release date is not
> > > enough. Working on JIT I see ~30 JIRA issues that may affect real
> > > applications, and running recently contributed test suites will reveal
> > > more. I think we should strive to fix most of them before the milestone,
> > > probably by the cost of limiting number of supported platforms. Then we may
> > > go to the next milestone, including more platforms/configurations.
> > >
> > >
> > >
> > > Having this in mind I propose to release M1 with IA32 support only, may be
> > > even limiting this support to Windows. Let's fix all stability problems
> > > there and then go to the next milestone shortly, including support for Linux
> > > or x86_64. I propose a feature freeze date of 15th of May and put M1 release
> > > date of 15th of June. At the feature freeze we should complete current
> > > development works and move on to stability to release a really mature
> > > runtime. We might have release an "release candidate" before the JavaOne
> > > which will have all the capabilities than our milestone build but without
> > > all stability issues fixed.
> > >
> > >
> > >
> > > I also have comments about configurations:
> > >
> > > *- IA32/x86 with a minimum of P3 (SSE, not SSE2)*
> > > **
> > > **
> > >
> > > SSE+SSE2 unless someone commits to test and complete on pure PIII.
> > > *- IA64/IPF (Intel 64-bit architecture)*
> > >
> > > DRLVM is poorly tested on IPF yet. This is rather for M3 milestone.
> > >
> > > *- x86_64/AMD64/EMT64 (AMD architecture)*
> > > Let's put this aside for the first release. We have some stability level
> > > there which is supported by CruiseControl and no regression on these
> > > platform is enough for the first release. I'm fine to include this into M1
> > > if someone commit to this.
> > >
> > > *- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > > Windows 2003 R2, (Windows Vista?)*
> > >
> > >
> > >
> > > + 1 for Windows 2003, Windows XP. It's interesting to try on Vista but I'd
> > > give it some time to "grow up" before we go there.
> >
> > Pavel, I personally would vote Linux32 for the first release. If Win32
> > is easier to achieve, we probably can make is an internal
> > (intermediate) milestone for the real Linux32 release. (Actually I
> > don't know if Win32 is easier than Linux32).
> >
> > Thanks,
> > xiaofeng
> >
> > >
> > > *- Linux; kernel v2.4.x, v2.6.x*
> > >
> > >
> > >
> > > I'm sure Geir will vote for Linux, but I'm reluctant to put everything in
> > > the first milestone.
> > >
> > >
> > > *- (FreeBSD v???)
> > > *
> > >
> > > Volunteers? ;-)
> > >
> > >
> > >
> > > Thank you,
> > >
> > > Pavel Ozhdikhin
> > >
> > > Intel Managed Runtime Division
> > >
> >
>
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
Hi Xiao Feng,
You probably missed this, but we have taken an internal Intel
target to release Harmony first on Win32 in Q2 after a lot of
discussions in Judy's JCM meeting, based primarily on feedback from
the JIT and performance teams.
Rana
On 4/2/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> On 4/3/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > On 4/3/07, Tim Ellison <t....@gmail.com> wrote:
> > >
> > > Nathan Beyer wrote:
> > > > However, from looking back on this mailing list thread, I couldn't
> > > > find any decision at the end of this or much of a consensus. I would
> > > > like to pull this together, vote on it. document it (site, Wiki, etc),
> > > > test it, etc.
> > >
> > > Agreed, let's try and get a consensus on what we will have in our M1
> > > build, and a date to shoot for it.
> > >
> > > I think we have a reasonable idea forming that it will be (taken from
> > > your list):
> > >
> > > - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> > > - IA64/IPF (Intel 64-bit architecture)
> > > - x86_64/AMD64/EMT64 (AMD architecture)
> > >
> > > - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > > Windows 2003 R2, (Windows Vista?)
> > > - Linux; kernel v2.4.x, v2.6.x
> > > - (FreeBSD v???)
> > >
> > > I've put some in parentheses since we need to hear from people what work
> > > is required to get them ready and stable. I also removed the priority
> > > order since I think they are all equally important if we declare them
> > > stable.
> > >
> > > An M1 date of April 30th would give us a stable build ready for
> > > ApacheCon EU and JavaOne, which seems like a good goal. Working
> > > backwards we would then focus on stability for whatever we have got from
> > > April 23.
> > >
> > > I wonder if the Win2000 goal is possible in that timeframe? If not I
> > > suggest we live with WinXP as a minimum requirement for M1. Do we know
> > > what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
> > > work remaining and we should drop it from M1 if so.
> > >
> > > Regards,
> > > Tim
> >
> >
> >
> > I think having a milestone we want to show a really fast and stable runtime
> > environment, not just another snapshot of what we have to the moment. If I'm
> > correct than 1 week between the feature freeze and release date is not
> > enough. Working on JIT I see ~30 JIRA issues that may affect real
> > applications, and running recently contributed test suites will reveal
> > more. I think we should strive to fix most of them before the milestone,
> > probably by the cost of limiting number of supported platforms. Then we may
> > go to the next milestone, including more platforms/configurations.
> >
> >
> >
> > Having this in mind I propose to release M1 with IA32 support only, may be
> > even limiting this support to Windows. Let's fix all stability problems
> > there and then go to the next milestone shortly, including support for Linux
> > or x86_64. I propose a feature freeze date of 15th of May and put M1 release
> > date of 15th of June. At the feature freeze we should complete current
> > development works and move on to stability to release a really mature
> > runtime. We might have release an "release candidate" before the JavaOne
> > which will have all the capabilities than our milestone build but without
> > all stability issues fixed.
> >
> >
> >
> > I also have comments about configurations:
> >
> > *- IA32/x86 with a minimum of P3 (SSE, not SSE2)*
> > **
> > **
> >
> > SSE+SSE2 unless someone commits to test and complete on pure PIII.
> > *- IA64/IPF (Intel 64-bit architecture)*
> >
> > DRLVM is poorly tested on IPF yet. This is rather for M3 milestone.
> >
> > *- x86_64/AMD64/EMT64 (AMD architecture)*
> > Let's put this aside for the first release. We have some stability level
> > there which is supported by CruiseControl and no regression on these
> > platform is enough for the first release. I'm fine to include this into M1
> > if someone commit to this.
> >
> > *- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > Windows 2003 R2, (Windows Vista?)*
> >
> >
> >
> > + 1 for Windows 2003, Windows XP. It's interesting to try on Vista but I'd
> > give it some time to "grow up" before we go there.
>
> Pavel, I personally would vote Linux32 for the first release. If Win32
> is easier to achieve, we probably can make is an internal
> (intermediate) milestone for the real Linux32 release. (Actually I
> don't know if Win32 is easier than Linux32).
>
> Thanks,
> xiaofeng
>
> >
> > *- Linux; kernel v2.4.x, v2.6.x*
> >
> >
> >
> > I'm sure Geir will vote for Linux, but I'm reluctant to put everything in
> > the first milestone.
> >
> >
> > *- (FreeBSD v???)
> > *
> >
> > Volunteers? ;-)
> >
> >
> >
> > Thank you,
> >
> > Pavel Ozhdikhin
> >
> > Intel Managed Runtime Division
> >
>
Re: [general] What platforms do we support?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2AD day of Apache Harmony Xiao-Feng Li wrote:
> On 4/3/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > On 4/3/07, Tim Ellison <t....@gmail.com> wrote:
> > >
> > > Nathan Beyer wrote:
> > > > However, from looking back on this mailing list thread, I couldn't
> > > > find any decision at the end of this or much of a consensus. I would
> > > > like to pull this together, vote on it. document it (site, Wiki, etc),
> > > > test it, etc.
> > >
> > > Agreed, let's try and get a consensus on what we will have in our M1
> > > build, and a date to shoot for it.
> > >
> > > I think we have a reasonable idea forming that it will be (taken from
> > > your list):
> > >
> > > - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> > > - IA64/IPF (Intel 64-bit architecture)
> > > - x86_64/AMD64/EMT64 (AMD architecture)
> > >
> > > - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > > Windows 2003 R2, (Windows Vista?)
> > > - Linux; kernel v2.4.x, v2.6.x
> > > - (FreeBSD v???)
> > >
> > > I've put some in parentheses since we need to hear from people what work
> > > is required to get them ready and stable. I also removed the priority
> > > order since I think they are all equally important if we declare them
> > > stable.
> > >
> > > An M1 date of April 30th would give us a stable build ready for
> > > ApacheCon EU and JavaOne, which seems like a good goal. Working
> > > backwards we would then focus on stability for whatever we have got from
> > > April 23.
> > >
> > > I wonder if the Win2000 goal is possible in that timeframe? If not I
> > > suggest we live with WinXP as a minimum requirement for M1. Do we know
> > > what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
> > > work remaining and we should drop it from M1 if so.
> > >
> > > Regards,
> > > Tim
> >
> >
> >
> > I think having a milestone we want to show a really fast and stable runtime
> > environment, not just another snapshot of what we have to the moment. If I'm
> > correct than 1 week between the feature freeze and release date is not
> > enough. Working on JIT I see ~30 JIRA issues that may affect real
> > applications, and running recently contributed test suites will reveal
> > more. I think we should strive to fix most of them before the milestone,
> > probably by the cost of limiting number of supported platforms. Then we may
> > go to the next milestone, including more platforms/configurations.
> >
> >
> >
> > Having this in mind I propose to release M1 with IA32 support only, may be
> > even limiting this support to Windows. Let's fix all stability problems
> > there and then go to the next milestone shortly, including support for Linux
> > or x86_64. I propose a feature freeze date of 15th of May and put M1 release
> > date of 15th of June. At the feature freeze we should complete current
> > development works and move on to stability to release a really mature
> > runtime. We might have release an "release candidate" before the JavaOne
> > which will have all the capabilities than our milestone build but without
> > all stability issues fixed.
> >
> >
> >
> > I also have comments about configurations:
> >
> > *- IA32/x86 with a minimum of P3 (SSE, not SSE2)*
> > **
> > **
> >
> > SSE+SSE2 unless someone commits to test and complete on pure PIII.
> > *- IA64/IPF (Intel 64-bit architecture)*
> >
> > DRLVM is poorly tested on IPF yet. This is rather for M3 milestone.
> >
> > *- x86_64/AMD64/EMT64 (AMD architecture)*
> > Let's put this aside for the first release. We have some stability level
> > there which is supported by CruiseControl and no regression on these
> > platform is enough for the first release. I'm fine to include this into M1
> > if someone commit to this.
> >
> > *- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > Windows 2003 R2, (Windows Vista?)*
> >
> >
> >
> > + 1 for Windows 2003, Windows XP. It's interesting to try on Vista but I'd
> > give it some time to "grow up" before we go there.
>
> Pavel, I personally would vote Linux32 for the first release. If Win32
> is easier to achieve, we probably can make is an internal
> (intermediate) milestone for the real Linux32 release. (Actually I
> don't know if Win32 is easier than Linux32).
+1
--
Egor Pasko
Re: [general] What platforms do we support?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/3/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> On 4/3/07, Tim Ellison <t....@gmail.com> wrote:
> >
> > Nathan Beyer wrote:
> > > However, from looking back on this mailing list thread, I couldn't
> > > find any decision at the end of this or much of a consensus. I would
> > > like to pull this together, vote on it. document it (site, Wiki, etc),
> > > test it, etc.
> >
> > Agreed, let's try and get a consensus on what we will have in our M1
> > build, and a date to shoot for it.
> >
> > I think we have a reasonable idea forming that it will be (taken from
> > your list):
> >
> > - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> > - IA64/IPF (Intel 64-bit architecture)
> > - x86_64/AMD64/EMT64 (AMD architecture)
> >
> > - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> > Windows 2003 R2, (Windows Vista?)
> > - Linux; kernel v2.4.x, v2.6.x
> > - (FreeBSD v???)
> >
> > I've put some in parentheses since we need to hear from people what work
> > is required to get them ready and stable. I also removed the priority
> > order since I think they are all equally important if we declare them
> > stable.
> >
> > An M1 date of April 30th would give us a stable build ready for
> > ApacheCon EU and JavaOne, which seems like a good goal. Working
> > backwards we would then focus on stability for whatever we have got from
> > April 23.
> >
> > I wonder if the Win2000 goal is possible in that timeframe? If not I
> > suggest we live with WinXP as a minimum requirement for M1. Do we know
> > what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
> > work remaining and we should drop it from M1 if so.
> >
> > Regards,
> > Tim
>
>
>
> I think having a milestone we want to show a really fast and stable runtime
> environment, not just another snapshot of what we have to the moment. If I'm
> correct than 1 week between the feature freeze and release date is not
> enough. Working on JIT I see ~30 JIRA issues that may affect real
> applications, and running recently contributed test suites will reveal
> more. I think we should strive to fix most of them before the milestone,
> probably by the cost of limiting number of supported platforms. Then we may
> go to the next milestone, including more platforms/configurations.
>
>
>
> Having this in mind I propose to release M1 with IA32 support only, may be
> even limiting this support to Windows. Let's fix all stability problems
> there and then go to the next milestone shortly, including support for Linux
> or x86_64. I propose a feature freeze date of 15th of May and put M1 release
> date of 15th of June. At the feature freeze we should complete current
> development works and move on to stability to release a really mature
> runtime. We might have release an "release candidate" before the JavaOne
> which will have all the capabilities than our milestone build but without
> all stability issues fixed.
>
>
>
> I also have comments about configurations:
>
> *- IA32/x86 with a minimum of P3 (SSE, not SSE2)*
> **
> **
>
> SSE+SSE2 unless someone commits to test and complete on pure PIII.
> *- IA64/IPF (Intel 64-bit architecture)*
>
> DRLVM is poorly tested on IPF yet. This is rather for M3 milestone.
>
> *- x86_64/AMD64/EMT64 (AMD architecture)*
> Let's put this aside for the first release. We have some stability level
> there which is supported by CruiseControl and no regression on these
> platform is enough for the first release. I'm fine to include this into M1
> if someone commit to this.
>
> *- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> Windows 2003 R2, (Windows Vista?)*
>
>
>
> + 1 for Windows 2003, Windows XP. It's interesting to try on Vista but I'd
> give it some time to "grow up" before we go there.
Pavel, I personally would vote Linux32 for the first release. If Win32
is easier to achieve, we probably can make is an internal
(intermediate) milestone for the real Linux32 release. (Actually I
don't know if Win32 is easier than Linux32).
Thanks,
xiaofeng
>
> *- Linux; kernel v2.4.x, v2.6.x*
>
>
>
> I'm sure Geir will vote for Linux, but I'm reluctant to put everything in
> the first milestone.
>
>
> *- (FreeBSD v???)
> *
>
> Volunteers? ;-)
>
>
>
> Thank you,
>
> Pavel Ozhdikhin
>
> Intel Managed Runtime Division
>
Re: [general] What platforms do we support?
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 4/3/07, Tim Ellison <t....@gmail.com> wrote:
>
> Nathan Beyer wrote:
> > However, from looking back on this mailing list thread, I couldn't
> > find any decision at the end of this or much of a consensus. I would
> > like to pull this together, vote on it. document it (site, Wiki, etc),
> > test it, etc.
>
> Agreed, let's try and get a consensus on what we will have in our M1
> build, and a date to shoot for it.
>
> I think we have a reasonable idea forming that it will be (taken from
> your list):
>
> - IA32/x86 with a minimum of P3 (SSE, not SSE2)
> - IA64/IPF (Intel 64-bit architecture)
> - x86_64/AMD64/EMT64 (AMD architecture)
>
> - (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
> Windows 2003 R2, (Windows Vista?)
> - Linux; kernel v2.4.x, v2.6.x
> - (FreeBSD v???)
>
> I've put some in parentheses since we need to hear from people what work
> is required to get them ready and stable. I also removed the priority
> order since I think they are all equally important if we declare them
> stable.
>
> An M1 date of April 30th would give us a stable build ready for
> ApacheCon EU and JavaOne, which seems like a good goal. Working
> backwards we would then focus on stability for whatever we have got from
> April 23.
>
> I wonder if the Win2000 goal is possible in that timeframe? If not I
> suggest we live with WinXP as a minimum requirement for M1. Do we know
> what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
> work remaining and we should drop it from M1 if so.
>
> Regards,
> Tim
I think having a milestone we want to show a really fast and stable runtime
environment, not just another snapshot of what we have to the moment. If I'm
correct than 1 week between the feature freeze and release date is not
enough. Working on JIT I see ~30 JIRA issues that may affect real
applications, and running recently contributed test suites will reveal
more. I think we should strive to fix most of them before the milestone,
probably by the cost of limiting number of supported platforms. Then we may
go to the next milestone, including more platforms/configurations.
Having this in mind I propose to release M1 with IA32 support only, may be
even limiting this support to Windows. Let's fix all stability problems
there and then go to the next milestone shortly, including support for Linux
or x86_64. I propose a feature freeze date of 15th of May and put M1 release
date of 15th of June. At the feature freeze we should complete current
development works and move on to stability to release a really mature
runtime. We might have release an "release candidate" before the JavaOne
which will have all the capabilities than our milestone build but without
all stability issues fixed.
I also have comments about configurations:
*- IA32/x86 with a minimum of P3 (SSE, not SSE2)*
**
**
SSE+SSE2 unless someone commits to test and complete on pure PIII.
*- IA64/IPF (Intel 64-bit architecture)*
DRLVM is poorly tested on IPF yet. This is rather for M3 milestone.
*- x86_64/AMD64/EMT64 (AMD architecture)*
Let's put this aside for the first release. We have some stability level
there which is supported by CruiseControl and no regression on these
platform is enough for the first release. I'm fine to include this into M1
if someone commit to this.
*- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
Windows 2003 R2, (Windows Vista?)*
+ 1 for Windows 2003, Windows XP. It's interesting to try on Vista but I'd
give it some time to "grow up" before we go there.
*- Linux; kernel v2.4.x, v2.6.x*
I'm sure Geir will vote for Linux, but I'm reluctant to put everything in
the first milestone.
*- (FreeBSD v???)
*
Volunteers? ;-)
Thank you,
Pavel Ozhdikhin
Intel Managed Runtime Division
Re: [general] What platforms do we support?
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> However, from looking back on this mailing list thread, I couldn't
> find any decision at the end of this or much of a consensus. I would
> like to pull this together, vote on it. document it (site, Wiki, etc),
> test it, etc.
Agreed, let's try and get a consensus on what we will have in our M1
build, and a date to shoot for it.
I think we have a reasonable idea forming that it will be (taken from
your list):
- IA32/x86 with a minimum of P3 (SSE, not SSE2)
- IA64/IPF (Intel 64-bit architecture)
- x86_64/AMD64/EMT64 (AMD architecture)
- (Windows 2000 SP4?), Windows XP SP2, Windows 2003,
Windows 2003 R2, (Windows Vista?)
- Linux; kernel v2.4.x, v2.6.x
- (FreeBSD v???)
I've put some in parentheses since we need to hear from people what work
is required to get them ready and stable. I also removed the priority
order since I think they are all equally important if we declare them
stable.
An M1 date of April 30th would give us a stable build ready for
ApacheCon EU and JavaOne, which seems like a good goal. Working
backwards we would then focus on stability for whatever we have got from
April 23.
I wonder if the Win2000 goal is possible in that timeframe? If not I
suggest we live with WinXP as a minimum requirement for M1. Do we know
what it takes to run on Vista/FreeBSD? Again I'm guessing non-trivial
work remaining and we should drop it from M1 if so.
Regards,
Tim
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
On 4/1/07, Mikhail Loenko <ml...@gmail.com> wrote:
> 2007/4/1, Nathan Beyer <nd...@apache.org>:
> > Yes, this is exactly my point. I would like to propose that the
> > following architectures and operating systems be supported (with the
> > following priority). Let's consider this a starting point for
> > discussion.
> >
> > 1. IA32 with a minimum of P3 (SSE, not SSE2)
> > 2. IA64/IPF (Intel 64-bit architecture)
> > 3. x86_64/AMD64 (AMD architecture)
> >
> > 1. Windows 2000 SP4, Windows XP SP2, Windows 2003, Windows 2003 R2,
> > Windows Vista
> > 1. Linux; kernel v2.4.x, v2.6.x
> > 2. FreeBSD v???
> >
> > -Nathan
>
> some time ago we had a discussion about what does "support" mean.
> (see "[general] POLL : supported platforms" thread)
>
> So which kind of support in terms of that discussion you are talking about?
I'm going by Geir's initial email in that thread [1].
<quote>
I think we can define "support" as - "one or more people in the
community tests on that platform on a regular basis, there are users
that use that platform, and we have people volunteering to find and fix
bugs that specifically affect that platform"
</quote>
However, from looking back on this mailing list thread, I couldn't
find any decision at the end of this or much of a consensus. I would
like to pull this together, vote on it. document it (site, Wiki, etc),
test it, etc.
-Nathan
[1] http://mail-archives.apache.org/mod_mbox/harmony-dev/200610.mbox/%3c4533ABF8.80303@pobox.com%3e
>
> Thanks,
> Mikhail
>
>
>
> >
> > On 3/31/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > > > > Currently, the downloads page [1] separates the available snapshots
> > > > into three platforms; Windows 32-bit, Linux 32-bit and Linux 64-bit.
> > > > All of these platforms are Intel-based x86, one would have to guess.
> > > > The Wiki has a section called "porting matrix" [2], which seems
> > > > specific to DRLVM. This seems to indicate that only the latest
> > > > platforms are supported; IA32 with SSE/SSE2 (what does that even
> > > > mean?) on Linux and WinXP/2003, IA64 and AMD64 on Linux.
> > > >
> > > > What I have found anecdotally is
> > > > * Classlib blows chunks on Windows 2000 because of the AWT/Swing code.
> > > > * DRLVM blows chunks, hard, on Pentium III and Pentium III Xeon systems
> > > > * IBM's VM works on Windows 2000, 2003, XP and on P3+ systems
> > > >
> > > > My point being, this is confusing. At the very least, it's not clearly
> > > > documented; does the classlib have different requirements or the same
> > > > as DRLVM? DRLVM can't run on P3 chips; isn't that a little silly? How
> > > > many P3-based servers are there out there that run J2EE app servers?
> > > >
> > > > Regardless, I think we need to come to a common understanding
> > > > (decision), document it and test against it.
> > > >
> > > > -
> > > I think the way the porting matrix was created was based on platforms
> > > of interest by several people, and the "+" signs indicated what ports
> > > people specifically signed up for. I assumed that it meant port of
> > > classlib and DRLVM . It was not intended to be specific to DRLVM, but
> > > to Harmony, as I understood it. Seen this way, it is still quite
> > > accurate, as I understand( maybe we should add x86_64 explicitly ).
> > >
> > > I agree with Nathan that the root of the confusion is what binaries we
> > > define as a Harmony release. If it is the classlib + DRLVM, the
> > > platforms supported will be the least common denominator platforms
> > > only. We will need to agree on this before we can consider any
> > > release.
> > >
> >
>
Re: [general] What platforms do we support?
Posted by Mikhail Loenko <ml...@gmail.com>.
2007/4/1, Nathan Beyer <nd...@apache.org>:
> Yes, this is exactly my point. I would like to propose that the
> following architectures and operating systems be supported (with the
> following priority). Let's consider this a starting point for
> discussion.
>
> 1. IA32 with a minimum of P3 (SSE, not SSE2)
> 2. IA64/IPF (Intel 64-bit architecture)
> 3. x86_64/AMD64 (AMD architecture)
>
> 1. Windows 2000 SP4, Windows XP SP2, Windows 2003, Windows 2003 R2,
> Windows Vista
> 1. Linux; kernel v2.4.x, v2.6.x
> 2. FreeBSD v???
>
> -Nathan
some time ago we had a discussion about what does "support" mean.
(see "[general] POLL : supported platforms" thread)
So which kind of support in terms of that discussion you are talking about?
Thanks,
Mikhail
>
> On 3/31/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > > > Currently, the downloads page [1] separates the available snapshots
> > > into three platforms; Windows 32-bit, Linux 32-bit and Linux 64-bit.
> > > All of these platforms are Intel-based x86, one would have to guess.
> > > The Wiki has a section called "porting matrix" [2], which seems
> > > specific to DRLVM. This seems to indicate that only the latest
> > > platforms are supported; IA32 with SSE/SSE2 (what does that even
> > > mean?) on Linux and WinXP/2003, IA64 and AMD64 on Linux.
> > >
> > > What I have found anecdotally is
> > > * Classlib blows chunks on Windows 2000 because of the AWT/Swing code.
> > > * DRLVM blows chunks, hard, on Pentium III and Pentium III Xeon systems
> > > * IBM's VM works on Windows 2000, 2003, XP and on P3+ systems
> > >
> > > My point being, this is confusing. At the very least, it's not clearly
> > > documented; does the classlib have different requirements or the same
> > > as DRLVM? DRLVM can't run on P3 chips; isn't that a little silly? How
> > > many P3-based servers are there out there that run J2EE app servers?
> > >
> > > Regardless, I think we need to come to a common understanding
> > > (decision), document it and test against it.
> > >
> > > -
> > I think the way the porting matrix was created was based on platforms
> > of interest by several people, and the "+" signs indicated what ports
> > people specifically signed up for. I assumed that it meant port of
> > classlib and DRLVM . It was not intended to be specific to DRLVM, but
> > to Harmony, as I understood it. Seen this way, it is still quite
> > accurate, as I understand( maybe we should add x86_64 explicitly ).
> >
> > I agree with Nathan that the root of the confusion is what binaries we
> > define as a Harmony release. If it is the classlib + DRLVM, the
> > platforms supported will be the least common denominator platforms
> > only. We will need to agree on this before we can consider any
> > release.
> >
>
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
Yes, this is exactly my point. I would like to propose that the
following architectures and operating systems be supported (with the
following priority). Let's consider this a starting point for
discussion.
1. IA32 with a minimum of P3 (SSE, not SSE2)
2. IA64/IPF (Intel 64-bit architecture)
3. x86_64/AMD64 (AMD architecture)
1. Windows 2000 SP4, Windows XP SP2, Windows 2003, Windows 2003 R2,
Windows Vista
1. Linux; kernel v2.4.x, v2.6.x
2. FreeBSD v???
-Nathan
On 3/31/07, Rana Dasgupta <rd...@gmail.com> wrote:
> On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > > Currently, the downloads page [1] separates the available snapshots
> > into three platforms; Windows 32-bit, Linux 32-bit and Linux 64-bit.
> > All of these platforms are Intel-based x86, one would have to guess.
> > The Wiki has a section called "porting matrix" [2], which seems
> > specific to DRLVM. This seems to indicate that only the latest
> > platforms are supported; IA32 with SSE/SSE2 (what does that even
> > mean?) on Linux and WinXP/2003, IA64 and AMD64 on Linux.
> >
> > What I have found anecdotally is
> > * Classlib blows chunks on Windows 2000 because of the AWT/Swing code.
> > * DRLVM blows chunks, hard, on Pentium III and Pentium III Xeon systems
> > * IBM's VM works on Windows 2000, 2003, XP and on P3+ systems
> >
> > My point being, this is confusing. At the very least, it's not clearly
> > documented; does the classlib have different requirements or the same
> > as DRLVM? DRLVM can't run on P3 chips; isn't that a little silly? How
> > many P3-based servers are there out there that run J2EE app servers?
> >
> > Regardless, I think we need to come to a common understanding
> > (decision), document it and test against it.
> >
> > -
> I think the way the porting matrix was created was based on platforms
> of interest by several people, and the "+" signs indicated what ports
> people specifically signed up for. I assumed that it meant port of
> classlib and DRLVM . It was not intended to be specific to DRLVM, but
> to Harmony, as I understood it. Seen this way, it is still quite
> accurate, as I understand( maybe we should add x86_64 explicitly ).
>
> I agree with Nathan that the root of the confusion is what binaries we
> define as a Harmony release. If it is the classlib + DRLVM, the
> platforms supported will be the least common denominator platforms
> only. We will need to agree on this before we can consider any
> release.
>
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > Currently, the downloads page [1] separates the available snapshots
> into three platforms; Windows 32-bit, Linux 32-bit and Linux 64-bit.
> All of these platforms are Intel-based x86, one would have to guess.
> The Wiki has a section called "porting matrix" [2], which seems
> specific to DRLVM. This seems to indicate that only the latest
> platforms are supported; IA32 with SSE/SSE2 (what does that even
> mean?) on Linux and WinXP/2003, IA64 and AMD64 on Linux.
>
> What I have found anecdotally is
> * Classlib blows chunks on Windows 2000 because of the AWT/Swing code.
> * DRLVM blows chunks, hard, on Pentium III and Pentium III Xeon systems
> * IBM's VM works on Windows 2000, 2003, XP and on P3+ systems
>
> My point being, this is confusing. At the very least, it's not clearly
> documented; does the classlib have different requirements or the same
> as DRLVM? DRLVM can't run on P3 chips; isn't that a little silly? How
> many P3-based servers are there out there that run J2EE app servers?
>
> Regardless, I think we need to come to a common understanding
> (decision), document it and test against it.
>
> -
I think the way the porting matrix was created was based on platforms
of interest by several people, and the "+" signs indicated what ports
people specifically signed up for. I assumed that it meant port of
classlib and DRLVM . It was not intended to be specific to DRLVM, but
to Harmony, as I understood it. Seen this way, it is still quite
accurate, as I understand( maybe we should add x86_64 explicitly ).
I agree with Nathan that the root of the confusion is what binaries we
define as a Harmony release. If it is the classlib + DRLVM, the
platforms supported will be the least common denominator platforms
only. We will need to agree on this before we can consider any
release.
Re: [general] What platforms do we support?
Posted by Rana Dasgupta <rd...@gmail.com>.
Centrino has full support for sse and sse2 instructions though it has
a basic PIII microarchitecture. The mfence instruction is a part of
the SSE2 branding. SSE2 is not available on P3 Xeon. So we are talking
of different platforms here, and Nathan's machine is expected to mark
mfence as an illegal instruction.
Nathan, looks like you will need to try running with the recent H-3246
patch mentioned on the other related thread "[drlvm] tests failing on
linux (Ubuntu 7.04-dev) with Quad Xeon P3". The patch does not mention
what platforms it was tested on. I hope that includes an old PIII
which almost none of us have.
On 4/2/07, Mikhail Fursov <mi...@gmail.com> wrote:
> On 4/1/07, Nathan Beyer <nd...@apache.org> wrote:
> >
> > I have Quad P3 Xeon server running Ubuntu and I can't run Classlib +
> > DRLVM because of some 'mfence' instruction. When's the last time you
> > tried this on a Centrino chip?
>
>
> Usually I try running DRLVM on my laptop once per week. I have just checked
> some spec applications and they passed OK.
>
>
> --
> Mikhail Fursov
>
Re: [general] What platforms do we support?
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/1/07, Nathan Beyer <nd...@apache.org> wrote:
>
> I have Quad P3 Xeon server running Ubuntu and I can't run Classlib +
> DRLVM because of some 'mfence' instruction. When's the last time you
> tried this on a Centrino chip?
Usually I try running DRLVM on my laptop once per week. I have just checked
some spec applications and they passed OK.
--
Mikhail Fursov
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
On 3/31/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > IA64 and AMD64 on Linux.
> add Windows x86_64 to the list too.
>
> >DRLVM can't run on P3 chips; isn't that a little silly?
> Every task has its priority. Looks like this task is not hot one today and
> becomes colder every month. + DRLVM runs fine on Centrino laptops (PIII)
> with SSE/SSE2 support.
I have Quad P3 Xeon server running Ubuntu and I can't run Classlib +
DRLVM because of some 'mfence' instruction. When's the last time you
tried this on a Centrino chip?
I also have a P3 server running Windows 2000 and I can't run Classlib
+ DRLVM either.
Personally, I think this is a bit embarrassing, considering I'm
running a Sun JDK 5 to build all of this code (I've also use JDK 6
without issue too).
-Nathan
>
>
> --
> Mikhail Fursov
>
Re: [general] What platforms do we support?
Posted by Mikhail Fursov <mi...@gmail.com>.
> IA64 and AMD64 on Linux.
add Windows x86_64 to the list too.
>DRLVM can't run on P3 chips; isn't that a little silly?
Every task has its priority. Looks like this task is not hot one today and
becomes colder every month. + DRLVM runs fine on Centrino laptops (PIII)
with SSE/SSE2 support.
--
Mikhail Fursov
Re: [classlib][awt/swing] Windows version dependencies? (was: Re: [general] What platforms do we support?)
Posted by Alexey Petrenko <al...@gmail.com>.
2007/4/10, Pavlenko, Andrey A <an...@intel.com>:
> I'll attach a new patch without asserts.
Andrey, your new patch does not check that DrawThemeBackground is found.
SY, Alexey
Re: [classlib][awt/swing] Windows version dependencies? (was: Re: [general] What platforms do we support?)
Posted by Alexey Petrenko <al...@gmail.com>.
2007/4/10, Pavlenko, Andrey A <an...@intel.com>:
> Alexey,
>
> AFAIU the method drawXpBackground() should not be invoked under win2000,
Ok, but then you should avoid calling of this method but not just call
assert inside.
SY, Alexey
> but if I'm not right the asserts should be removed. I'll attach a new
> patch without asserts.
>
> -----Original Message-----
> From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> Sent: Monday, April 09, 2007 11:13 PM
> To: dev@harmony.apache.org
> Subject: Re: [classlib][awt/swing] Windows version dependencies? (was:
> Re: [general] What platforms do we support?)
>
> Andrey,
>
> AFAIU your patch will fail on assert call if there is no uxtheme.dll
> or DrawThemeBackground function in it, will not it?
>
> SY, Alexey
>
> 2007/4/9, Pavlenko, Andrey A <an...@intel.com>:
> > I've attached a patch, but I haven't win2000 to check if this patch
> > fixes the issue.
> >
> > Could somebody check it?
> >
> > -----Original Message-----
> > From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> > Sent: Wednesday, April 04, 2007 11:54 AM
> > To: dev@harmony.apache.org
> > Subject: Re: [classlib][awt/swing] Windows version dependencies? (was:
> > Re: [general] What platforms do we support?)
> >
> > I've created corresponding JIRA issue:
> > https://issues.apache.org/jira/browse/HARMONY-3569
> >
> > SY, Alexey
> >
> > 2007/4/4, Alexey Petrenko <al...@gmail.com>:
> > > As I replied to Nathan before, yes, it looks like we can make this
> > > dependency optional.
> > >
> > > SY, Alexey
> > >
> > > 2007/4/2, Tim Ellison <t....@gmail.com>:
> > > > Nathan Beyer wrote:
> > > > > On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> > > > >> I'd call out the current Windows OS support as "Windows 2000
> > > > >> Professional with SP3, or better". Not sure that we have anyone
> > testing
> > > > >> on that version, but I'd be interested to know if people don't
> > think
> > > > >> that is achievable.
> > > > >
> > > > > I have a Windows 2000 (on a P3) box running buildtest now, but
> > it's
> > > > > blowing up. I couldn't get DRLVM to do much of anything. The
> > classlib
> > > > > + ibmvm runs, but the tests for AWT/Swing always fail because
> > they're
> > > > > dependent on some XP/2003 library.
> > > >
> > > > Can anyone tell us what it will take to get AWT and Swing to work
> on
> > > > Windows 2000?
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > >
> >
>
Re: [classlib][awt/swing] Windows version dependencies? (was: Re: [general] What platforms do we support?)
Posted by Alexey Petrenko <al...@gmail.com>.
So I was right in my concerns...
I would change the patch to something like the following...
=== cut ===
static void (__stdcall *drawThemeBackground) (void*, void*, int, int,
void*, void*) = NULL;
static int isUxThemeAvailable = 1;
JNIEXPORT void JNICALL
Java_org_apache_harmony_awt_theme_windows_WinThemeGraphics_drawXpBackground
(JNIEnv * env, jclass clazz, jlong gip, jint x, jint y, jint
w, jint h,
jlong hTheme, jint type, jint state) {
if (isUxThemeAvailable && drawThemeBackground == NULL) {
HMODULE libUxTheme = LoadLibrary("UxTheme");
isUxThemeAvailable = libUxTheme != NULL;
if (isUxThemeAvailable) {
drawThemeBackground = (void (__stdcall *) (void*, void*,
int, int, void*, void*)) GetProcAddress(libUxTheme,
"DrawThemeBackground");
isUxThemeAvailable = drawThemeBackground != NULL;
}
}
if (!isUxThemeAvailable)
return;
GraphicsInfo *gi = (GraphicsInfo *)gip;
RECT bounds = { (int)x, (int)y, (int)x + (int)w, (int)y + (int)h };
drawThemeBackground((void*) hTheme, (void*) gi->hdc, (int) type,
(int) state, (void*) &bounds, (void*) NULL);
}
=== cut ===
Disclaimer. I've never tested this code and I'm diving in Egypt. So I
do not guarantee that this code is ok! :)
SY, Alexey
2007/4/10, Nathan Beyer <nd...@apache.org>:
> Yeah, that's what it is doing. The tests are just being reported as VM
> crashes.
>
> What's the intention of this patch? I thought it was to make
> uxtheme.dll optional, but it just fails it in a different way.
>
> -Nathan
>
> On 4/9/07, Alexey Petrenko <al...@gmail.com> wrote:
> > Andrey,
> >
> > AFAIU your patch will fail on assert call if there is no uxtheme.dll
> > or DrawThemeBackground function in it, will not it?
> >
> > SY, Alexey
> >
> > 2007/4/9, Pavlenko, Andrey A <an...@intel.com>:
> > > I've attached a patch, but I haven't win2000 to check if this patch
> > > fixes the issue.
> > >
> > > Could somebody check it?
> > >
> > > -----Original Message-----
> > > From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> > > Sent: Wednesday, April 04, 2007 11:54 AM
> > > To: dev@harmony.apache.org
> > > Subject: Re: [classlib][awt/swing] Windows version dependencies? (was:
> > > Re: [general] What platforms do we support?)
> > >
> > > I've created corresponding JIRA issue:
> > > https://issues.apache.org/jira/browse/HARMONY-3569
> > >
> > > SY, Alexey
> > >
> > > 2007/4/4, Alexey Petrenko <al...@gmail.com>:
> > > > As I replied to Nathan before, yes, it looks like we can make this
> > > > dependency optional.
> > > >
> > > > SY, Alexey
> > > >
> > > > 2007/4/2, Tim Ellison <t....@gmail.com>:
> > > > > Nathan Beyer wrote:
> > > > > > On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> > > > > >> I'd call out the current Windows OS support as "Windows 2000
> > > > > >> Professional with SP3, or better". Not sure that we have anyone
> > > testing
> > > > > >> on that version, but I'd be interested to know if people don't
> > > think
> > > > > >> that is achievable.
> > > > > >
> > > > > > I have a Windows 2000 (on a P3) box running buildtest now, but
> > > it's
> > > > > > blowing up. I couldn't get DRLVM to do much of anything. The
> > > classlib
> > > > > > + ibmvm runs, but the tests for AWT/Swing always fail because
> > > they're
> > > > > > dependent on some XP/2003 library.
> > > > >
> > > > > Can anyone tell us what it will take to get AWT and Swing to work on
> > > > > Windows 2000?
> > > > >
> > > > > Regards,
> > > > > Tim
> > > > >
> > > >
> > >
> >
>
Re: [classlib][awt/swing] Windows version dependencies? (was: Re: [general] What platforms do we support?)
Posted by Nathan Beyer <nd...@apache.org>.
Yeah, that's what it is doing. The tests are just being reported as VM crashes.
What's the intention of this patch? I thought it was to make
uxtheme.dll optional, but it just fails it in a different way.
-Nathan
On 4/9/07, Alexey Petrenko <al...@gmail.com> wrote:
> Andrey,
>
> AFAIU your patch will fail on assert call if there is no uxtheme.dll
> or DrawThemeBackground function in it, will not it?
>
> SY, Alexey
>
> 2007/4/9, Pavlenko, Andrey A <an...@intel.com>:
> > I've attached a patch, but I haven't win2000 to check if this patch
> > fixes the issue.
> >
> > Could somebody check it?
> >
> > -----Original Message-----
> > From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> > Sent: Wednesday, April 04, 2007 11:54 AM
> > To: dev@harmony.apache.org
> > Subject: Re: [classlib][awt/swing] Windows version dependencies? (was:
> > Re: [general] What platforms do we support?)
> >
> > I've created corresponding JIRA issue:
> > https://issues.apache.org/jira/browse/HARMONY-3569
> >
> > SY, Alexey
> >
> > 2007/4/4, Alexey Petrenko <al...@gmail.com>:
> > > As I replied to Nathan before, yes, it looks like we can make this
> > > dependency optional.
> > >
> > > SY, Alexey
> > >
> > > 2007/4/2, Tim Ellison <t....@gmail.com>:
> > > > Nathan Beyer wrote:
> > > > > On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> > > > >> I'd call out the current Windows OS support as "Windows 2000
> > > > >> Professional with SP3, or better". Not sure that we have anyone
> > testing
> > > > >> on that version, but I'd be interested to know if people don't
> > think
> > > > >> that is achievable.
> > > > >
> > > > > I have a Windows 2000 (on a P3) box running buildtest now, but
> > it's
> > > > > blowing up. I couldn't get DRLVM to do much of anything. The
> > classlib
> > > > > + ibmvm runs, but the tests for AWT/Swing always fail because
> > they're
> > > > > dependent on some XP/2003 library.
> > > >
> > > > Can anyone tell us what it will take to get AWT and Swing to work on
> > > > Windows 2000?
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > >
> >
>
RE: [classlib][awt/swing] Windows version dependencies? (was: Re: [general] What platforms do we support?)
Posted by "Pavlenko, Andrey A" <an...@intel.com>.
Alexey,
AFAIU the method drawXpBackground() should not be invoked under win2000,
but if I'm not right the asserts should be removed. I'll attach a new
patch without asserts.
-----Original Message-----
From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
Sent: Monday, April 09, 2007 11:13 PM
To: dev@harmony.apache.org
Subject: Re: [classlib][awt/swing] Windows version dependencies? (was:
Re: [general] What platforms do we support?)
Andrey,
AFAIU your patch will fail on assert call if there is no uxtheme.dll
or DrawThemeBackground function in it, will not it?
SY, Alexey
2007/4/9, Pavlenko, Andrey A <an...@intel.com>:
> I've attached a patch, but I haven't win2000 to check if this patch
> fixes the issue.
>
> Could somebody check it?
>
> -----Original Message-----
> From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> Sent: Wednesday, April 04, 2007 11:54 AM
> To: dev@harmony.apache.org
> Subject: Re: [classlib][awt/swing] Windows version dependencies? (was:
> Re: [general] What platforms do we support?)
>
> I've created corresponding JIRA issue:
> https://issues.apache.org/jira/browse/HARMONY-3569
>
> SY, Alexey
>
> 2007/4/4, Alexey Petrenko <al...@gmail.com>:
> > As I replied to Nathan before, yes, it looks like we can make this
> > dependency optional.
> >
> > SY, Alexey
> >
> > 2007/4/2, Tim Ellison <t....@gmail.com>:
> > > Nathan Beyer wrote:
> > > > On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> > > >> I'd call out the current Windows OS support as "Windows 2000
> > > >> Professional with SP3, or better". Not sure that we have anyone
> testing
> > > >> on that version, but I'd be interested to know if people don't
> think
> > > >> that is achievable.
> > > >
> > > > I have a Windows 2000 (on a P3) box running buildtest now, but
> it's
> > > > blowing up. I couldn't get DRLVM to do much of anything. The
> classlib
> > > > + ibmvm runs, but the tests for AWT/Swing always fail because
> they're
> > > > dependent on some XP/2003 library.
> > >
> > > Can anyone tell us what it will take to get AWT and Swing to work
on
> > > Windows 2000?
> > >
> > > Regards,
> > > Tim
> > >
> >
>
Re: [classlib][awt/swing] Windows version dependencies? (was: Re: [general] What platforms do we support?)
Posted by Alexey Petrenko <al...@gmail.com>.
Andrey,
AFAIU your patch will fail on assert call if there is no uxtheme.dll
or DrawThemeBackground function in it, will not it?
SY, Alexey
2007/4/9, Pavlenko, Andrey A <an...@intel.com>:
> I've attached a patch, but I haven't win2000 to check if this patch
> fixes the issue.
>
> Could somebody check it?
>
> -----Original Message-----
> From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> Sent: Wednesday, April 04, 2007 11:54 AM
> To: dev@harmony.apache.org
> Subject: Re: [classlib][awt/swing] Windows version dependencies? (was:
> Re: [general] What platforms do we support?)
>
> I've created corresponding JIRA issue:
> https://issues.apache.org/jira/browse/HARMONY-3569
>
> SY, Alexey
>
> 2007/4/4, Alexey Petrenko <al...@gmail.com>:
> > As I replied to Nathan before, yes, it looks like we can make this
> > dependency optional.
> >
> > SY, Alexey
> >
> > 2007/4/2, Tim Ellison <t....@gmail.com>:
> > > Nathan Beyer wrote:
> > > > On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> > > >> I'd call out the current Windows OS support as "Windows 2000
> > > >> Professional with SP3, or better". Not sure that we have anyone
> testing
> > > >> on that version, but I'd be interested to know if people don't
> think
> > > >> that is achievable.
> > > >
> > > > I have a Windows 2000 (on a P3) box running buildtest now, but
> it's
> > > > blowing up. I couldn't get DRLVM to do much of anything. The
> classlib
> > > > + ibmvm runs, but the tests for AWT/Swing always fail because
> they're
> > > > dependent on some XP/2003 library.
> > >
> > > Can anyone tell us what it will take to get AWT and Swing to work on
> > > Windows 2000?
> > >
> > > Regards,
> > > Tim
> > >
> >
>
Re: [classlib][awt/swing] Windows version dependencies? (was: Re: [general] What platforms do we support?)
Posted by Nathan Beyer <nd...@apache.org>.
Sweet. I'm looking at it and testing it now. Thanks.
-Nathan
On 4/9/07, Pavlenko, Andrey A <an...@intel.com> wrote:
> I've attached a patch, but I haven't win2000 to check if this patch
> fixes the issue.
>
> Could somebody check it?
>
> -----Original Message-----
> From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> Sent: Wednesday, April 04, 2007 11:54 AM
> To: dev@harmony.apache.org
> Subject: Re: [classlib][awt/swing] Windows version dependencies? (was:
> Re: [general] What platforms do we support?)
>
> I've created corresponding JIRA issue:
> https://issues.apache.org/jira/browse/HARMONY-3569
>
> SY, Alexey
>
> 2007/4/4, Alexey Petrenko <al...@gmail.com>:
> > As I replied to Nathan before, yes, it looks like we can make this
> > dependency optional.
> >
> > SY, Alexey
> >
> > 2007/4/2, Tim Ellison <t....@gmail.com>:
> > > Nathan Beyer wrote:
> > > > On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> > > >> I'd call out the current Windows OS support as "Windows 2000
> > > >> Professional with SP3, or better". Not sure that we have anyone
> testing
> > > >> on that version, but I'd be interested to know if people don't
> think
> > > >> that is achievable.
> > > >
> > > > I have a Windows 2000 (on a P3) box running buildtest now, but
> it's
> > > > blowing up. I couldn't get DRLVM to do much of anything. The
> classlib
> > > > + ibmvm runs, but the tests for AWT/Swing always fail because
> they're
> > > > dependent on some XP/2003 library.
> > >
> > > Can anyone tell us what it will take to get AWT and Swing to work on
> > > Windows 2000?
> > >
> > > Regards,
> > > Tim
> > >
> >
>
RE: [classlib][awt/swing] Windows version dependencies? (was: Re: [general] What platforms do we support?)
Posted by "Pavlenko, Andrey A" <an...@intel.com>.
I've attached a patch, but I haven't win2000 to check if this patch
fixes the issue.
Could somebody check it?
-----Original Message-----
From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
Sent: Wednesday, April 04, 2007 11:54 AM
To: dev@harmony.apache.org
Subject: Re: [classlib][awt/swing] Windows version dependencies? (was:
Re: [general] What platforms do we support?)
I've created corresponding JIRA issue:
https://issues.apache.org/jira/browse/HARMONY-3569
SY, Alexey
2007/4/4, Alexey Petrenko <al...@gmail.com>:
> As I replied to Nathan before, yes, it looks like we can make this
> dependency optional.
>
> SY, Alexey
>
> 2007/4/2, Tim Ellison <t....@gmail.com>:
> > Nathan Beyer wrote:
> > > On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> > >> I'd call out the current Windows OS support as "Windows 2000
> > >> Professional with SP3, or better". Not sure that we have anyone
testing
> > >> on that version, but I'd be interested to know if people don't
think
> > >> that is achievable.
> > >
> > > I have a Windows 2000 (on a P3) box running buildtest now, but
it's
> > > blowing up. I couldn't get DRLVM to do much of anything. The
classlib
> > > + ibmvm runs, but the tests for AWT/Swing always fail because
they're
> > > dependent on some XP/2003 library.
> >
> > Can anyone tell us what it will take to get AWT and Swing to work on
> > Windows 2000?
> >
> > Regards,
> > Tim
> >
>
Re: [classlib][awt/swing] Windows version dependencies? (was: Re: [general] What platforms do we support?)
Posted by Alexey Petrenko <al...@gmail.com>.
I've created corresponding JIRA issue:
https://issues.apache.org/jira/browse/HARMONY-3569
SY, Alexey
2007/4/4, Alexey Petrenko <al...@gmail.com>:
> As I replied to Nathan before, yes, it looks like we can make this
> dependency optional.
>
> SY, Alexey
>
> 2007/4/2, Tim Ellison <t....@gmail.com>:
> > Nathan Beyer wrote:
> > > On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> > >> I'd call out the current Windows OS support as "Windows 2000
> > >> Professional with SP3, or better". Not sure that we have anyone testing
> > >> on that version, but I'd be interested to know if people don't think
> > >> that is achievable.
> > >
> > > I have a Windows 2000 (on a P3) box running buildtest now, but it's
> > > blowing up. I couldn't get DRLVM to do much of anything. The classlib
> > > + ibmvm runs, but the tests for AWT/Swing always fail because they're
> > > dependent on some XP/2003 library.
> >
> > Can anyone tell us what it will take to get AWT and Swing to work on
> > Windows 2000?
> >
> > Regards,
> > Tim
> >
>
Re: [classlib][awt/swing] Windows version dependencies? (was: Re: [general] What platforms do we support?)
Posted by Alexey Petrenko <al...@gmail.com>.
As I replied to Nathan before, yes, it looks like we can make this
dependency optional.
SY, Alexey
2007/4/2, Tim Ellison <t....@gmail.com>:
> Nathan Beyer wrote:
> > On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> >> I'd call out the current Windows OS support as "Windows 2000
> >> Professional with SP3, or better". Not sure that we have anyone testing
> >> on that version, but I'd be interested to know if people don't think
> >> that is achievable.
> >
> > I have a Windows 2000 (on a P3) box running buildtest now, but it's
> > blowing up. I couldn't get DRLVM to do much of anything. The classlib
> > + ibmvm runs, but the tests for AWT/Swing always fail because they're
> > dependent on some XP/2003 library.
>
> Can anyone tell us what it will take to get AWT and Swing to work on
> Windows 2000?
>
> Regards,
> Tim
>
[classlib][awt/swing] Windows version dependencies? (was: Re: [general]
What platforms do we support?)
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
>> I'd call out the current Windows OS support as "Windows 2000
>> Professional with SP3, or better". Not sure that we have anyone testing
>> on that version, but I'd be interested to know if people don't think
>> that is achievable.
>
> I have a Windows 2000 (on a P3) box running buildtest now, but it's
> blowing up. I couldn't get DRLVM to do much of anything. The classlib
> + ibmvm runs, but the tests for AWT/Swing always fail because they're
> dependent on some XP/2003 library.
Can anyone tell us what it will take to get AWT and Swing to work on
Windows 2000?
Regards,
Tim
Re: [general] What platforms do we support?
Posted by Nathan Beyer <nd...@apache.org>.
On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> Nathan Beyer wrote:
> > Over the past few months I've been experimenting with various platform
> > configurations to run the build tests on and I've been running into
> > enormous hurdles that seem to all be turning out to be undocumented
> > platform requirements.
> >
> > Currently, the downloads page [1] separates the available snapshots
> > into three platforms; Windows 32-bit, Linux 32-bit and Linux 64-bit.
> > All of these platforms are Intel-based x86, one would have to guess.
>
> I agree we should have explicit machine requirements listed alongside
> the download links.
>
> > The Wiki has a section called "porting matrix" [2], which seems
> > specific to DRLVM.
>
> That should cover both DRLVM and the class library code.
>
> > This seems to indicate that only the latest
> > platforms are supported; IA32 with SSE/SSE2 (what does that even
> > mean?) on Linux and WinXP/2003, IA64 and AMD64 on Linux.
>
> SSE/SSE2 refers to the extended instruction set.
>
> > What I have found anecdotally is
> > * Classlib blows chunks on Windows 2000 because of the AWT/Swing code.
> > * DRLVM blows chunks, hard, on Pentium III and Pentium III Xeon systems
> > * IBM's VM works on Windows 2000, 2003, XP and on P3+ systems
> >
> > My point being, this is confusing. At the very least, it's not clearly
> > documented; does the classlib have different requirements or the same
> > as DRLVM? DRLVM can't run on P3 chips; isn't that a little silly? How
> > many P3-based servers are there out there that run J2EE app servers?
> >
> > Regardless, I think we need to come to a common understanding
> > (decision), document it and test against it.
>
> We sure can do a better job of describing the current requirements. We
> could also agree on what platforms (OS/processor combinations) are most
> interesting, but of course it requires work to ensure ongoing 'support'
> for each one. Without people stepping up to provide code and testing
> etc. then a platform will fall into disrepair. Similarly, if somebody
> is willing to invest their time in a platform we don't think is
> interesting I doubt we would stop them. So we've kinda got what we've got.
>
> The Porting Matrix table is looking pretty good. We can fix up a few bits.
>
> I'd call out the current IA32 processor support as "Intel Pentium 3 CPU
> with MMX, SSE, and SSE2 support (i.e. Centrino) or better". You may be
> able to persuade the VM/JIT people to codegen for a regular Pentium 3
> with MMX, and SSE, the class library doesn't really care.
>
> I'd call out the current Windows OS support as "Windows 2000
> Professional with SP3, or better". Not sure that we have anyone testing
> on that version, but I'd be interested to know if people don't think
> that is achievable.
I have a Windows 2000 (on a P3) box running buildtest now, but it's
blowing up. I couldn't get DRLVM to do much of anything. The classlib
+ ibmvm runs, but the tests for AWT/Swing always fail because they're
dependent on some XP/2003 library.
-Nathan
>
> For Linux we can go through each distro's naming scheme, but I suggest
> they will all be 2.4.x kernels, or better.
>
> Thoughts?
> Tim
>
>
Re: [general] What platforms do we support?
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> Over the past few months I've been experimenting with various platform
> configurations to run the build tests on and I've been running into
> enormous hurdles that seem to all be turning out to be undocumented
> platform requirements.
>
> Currently, the downloads page [1] separates the available snapshots
> into three platforms; Windows 32-bit, Linux 32-bit and Linux 64-bit.
> All of these platforms are Intel-based x86, one would have to guess.
I agree we should have explicit machine requirements listed alongside
the download links.
> The Wiki has a section called "porting matrix" [2], which seems
> specific to DRLVM.
That should cover both DRLVM and the class library code.
> This seems to indicate that only the latest
> platforms are supported; IA32 with SSE/SSE2 (what does that even
> mean?) on Linux and WinXP/2003, IA64 and AMD64 on Linux.
SSE/SSE2 refers to the extended instruction set.
> What I have found anecdotally is
> * Classlib blows chunks on Windows 2000 because of the AWT/Swing code.
> * DRLVM blows chunks, hard, on Pentium III and Pentium III Xeon systems
> * IBM's VM works on Windows 2000, 2003, XP and on P3+ systems
>
> My point being, this is confusing. At the very least, it's not clearly
> documented; does the classlib have different requirements or the same
> as DRLVM? DRLVM can't run on P3 chips; isn't that a little silly? How
> many P3-based servers are there out there that run J2EE app servers?
>
> Regardless, I think we need to come to a common understanding
> (decision), document it and test against it.
We sure can do a better job of describing the current requirements. We
could also agree on what platforms (OS/processor combinations) are most
interesting, but of course it requires work to ensure ongoing 'support'
for each one. Without people stepping up to provide code and testing
etc. then a platform will fall into disrepair. Similarly, if somebody
is willing to invest their time in a platform we don't think is
interesting I doubt we would stop them. So we've kinda got what we've got.
The Porting Matrix table is looking pretty good. We can fix up a few bits.
I'd call out the current IA32 processor support as "Intel Pentium 3 CPU
with MMX, SSE, and SSE2 support (i.e. Centrino) or better". You may be
able to persuade the VM/JIT people to codegen for a regular Pentium 3
with MMX, and SSE, the class library doesn't really care.
I'd call out the current Windows OS support as "Windows 2000
Professional with SP3, or better". Not sure that we have anyone testing
on that version, but I'd be interested to know if people don't think
that is achievable.
For Linux we can go through each distro's naming scheme, but I suggest
they will all be 2.4.x kernels, or better.
Thoughts?
Tim
Re: [general] What platforms do we support?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2AA day of Apache Harmony Nathan Beyer wrote:
> Over the past few months I've been experimenting with various platform
> configurations to run the build tests on and I've been running into
> enormous hurdles that seem to all be turning out to be undocumented
> platform requirements.
>
> Currently, the downloads page [1] separates the available snapshots
> into three platforms; Windows 32-bit, Linux 32-bit and Linux 64-bit.
> All of these platforms are Intel-based x86, one would have to guess.
> The Wiki has a section called "porting matrix" [2], which seems
> specific to DRLVM. This seems to indicate that only the latest
> platforms are supported; IA32 with SSE/SSE2 (what does that even
> mean?) on Linux and WinXP/2003, IA64 and AMD64 on Linux.
>
> What I have found anecdotally is
> * Classlib blows chunks on Windows 2000 because of the AWT/Swing code.
> * DRLVM blows chunks, hard, on Pentium III and Pentium III Xeon systems
> * IBM's VM works on Windows 2000, 2003, XP and on P3+ systems
>
> My point being, this is confusing. At the very least, it's not clearly
> documented; does the classlib have different requirements or the same
> as DRLVM? DRLVM can't run on P3 chips; isn't that a little silly? How
> many P3-based servers are there out there that run J2EE app servers?
there is HARMONY-3246 that is intended to solve this problem (patch
available). Some day it is going to be committed. Is it critical?
> Regardless, I think we need to come to a common understanding
> (decision), document it and test against it.
>
> -Nathan
>
> [1] http://harmony.apache.org/downloads.html
> [2] http://harmony.apache.org/roadmap.html#Porting%20Matrix
>
--
Egor Pasko