You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "cyang.cq" <cy...@gmail.com> on 2007/09/24 09:45:15 UTC
[drlvm][thread]scalability problem
Hi, all
The scalability of the program below is surprising on M2.
This program only starts several threads to share the work
of doing a number of additions.
MT.java:
public class MT extends Thread{
static long result = 0;
long len = 0;
public MT(long len){
this.len = len;
}
public void run(){
long total = 0;
for(long i = 0; i < len; ++i){
total += 1;
}
result = total;
}
public static void main(String[] args) throws InterruptedException {
long totalWork = Long.parseLong(args[0]);
int numThreads = Integer.parseInt(args[1]);
long work = totalWork / numThreads;
MT[] v = new MT[numThreads];
for(int i = 0; i < numThreads; ++i){
v[i] = new MT(work);
}
long start = System.currentTimeMillis();
for(int i = 0; i < numThreads; ++i){
v[i].start();
}
for(int i = 0; i < numThreads; ++i){
v[i].join();
}
long dur = System.currentTimeMillis() - start;
System.out.println("Total time: " + dur);
}
}
Run it on 5.0M2:
CMD OUTPUT
java MT 9000000000 1 Total time: 411325
java MT 9000000000 2 Total time: 1052861
java MT 9000000000 4 Total time: 915545
java MT 9000000000 8 Total time: 589672
java MT 9000000000 12 Total time: 678815
java MT 9000000000 16 Total time: 621097
Run it on sun jdk 1.5.0_08:
CMD OUTPUT
java MT 9000000000 1 Total time: 10356
java MT 9000000000 2 Total time: 5182
java MT 9000000000 4 Total time: 2601
java MT 9000000000 8 Total time: 1453
java MT 9000000000 12 Total time: 1004
java MT 9000000000 16 Total time: 782
My configuration is:
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
Kernel 2.6.9-42.ELlargesmp on an x86_64
CPU: 8 X Dual-Core AMD Opteron 2.6G
Mem: 16G
drlvm: Apache Harmony 5.0M2 JRE for 32-bit Linux
for systems with libstdc++.so.5
sun jdk: jdk-1_5_0_08-linux-i586
Any suggestions? Have this been fixed already since M2?
Thanks in advance.
Re: [drlvm][thread]scalability problem
Posted by Yuri Dolgov <do...@gmail.com>.
Hello,
Thanks a lot for the finding. I've spend a while trying to understand the
reason of such behavior, no much progress so far. But I found out that such
behavior is only appeared in interpreter or JET modes, so quick fix for such
situation would be using Harmony with option -Xem:opt. In opt mode I got
better than linear scalability:
java -Xem:opt MT 9000000000 1
Total time: 20219
java -Xem:opt MT 9000000000 2
Total time: 10140
java -Xem:opt MT 9000000000 4
Total time: 4625
java -Xem:opt MT 9000000000 8
Total time: 2485
java -Xem:opt MT 9000000000 16
Total time: 2500
I used Dual processor Quad Core Xeon(r) 5355 (8 Cores total) 2.67 GHz, 4 Gb of
RAM with Windows Server 2003 OS and Harmony r571439.
I'll do some deeper analysis on reasons of such behavior on JET and
interpreter.
Thanks,
Yuri
On 9/24/07, cyang.cq <cy...@gmail.com> wrote:
>
> Hi, all
> The scalability of the program below is surprising on M2.
> This program only starts several threads to share the work
> of doing a number of additions.
>
> MT.java:
>
> public class MT extends Thread{
>
> static long result = 0;
> long len = 0;
> public MT(long len){
> this.len = len;
> }
>
> public void run(){
> long total = 0;
> for(long i = 0; i < len; ++i){
> total += 1;
> }
> result = total;
> }
>
> public static void main(String[] args) throws InterruptedException {
> long totalWork = Long.parseLong(args[0]);
> int numThreads = Integer.parseInt(args[1]);
>
> long work = totalWork / numThreads;
>
> MT[] v = new MT[numThreads];
> for(int i = 0; i < numThreads; ++i){
> v[i] = new MT(work);
> }
>
> long start = System.currentTimeMillis();
> for(int i = 0; i < numThreads; ++i){
> v[i].start();
> }
> for(int i = 0; i < numThreads; ++i){
> v[i].join();
> }
> long dur = System.currentTimeMillis() - start;
>
> System.out.println("Total time: " + dur);
> }
>
> }
>
> Run it on 5.0M2:
> CMD OUTPUT
> java MT 9000000000 1 Total time: 411325
> java MT 9000000000 2 Total time: 1052861
> java MT 9000000000 4 Total time: 915545
> java MT 9000000000 8 Total time: 589672
> java MT 9000000000 12 Total time: 678815
> java MT 9000000000 16 Total time: 621097
>
>
> Run it on sun jdk 1.5.0_08:
> CMD OUTPUT
> java MT 9000000000 1 Total time: 10356
> java MT 9000000000 2 Total time: 5182
> java MT 9000000000 4 Total time: 2601
> java MT 9000000000 8 Total time: 1453
> java MT 9000000000 12 Total time: 1004
> java MT 9000000000 16 Total time: 782
>
>
>
> My configuration is:
> OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
> Kernel 2.6.9-42.ELlargesmp on an x86_64
> CPU: 8 X Dual-Core AMD Opteron 2.6G
> Mem: 16G
> drlvm: Apache Harmony 5.0M2 JRE for 32-bit Linux
> for systems with libstdc++.so.5
> sun jdk: jdk-1_5_0_08-linux-i586
>
>
> Any suggestions? Have this been fixed already since M2?
>
> Thanks in advance.
Re: [drlvm][thread]scalability problem
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
The result of the test with the patch applied looks great! Thanks, Yuri.
Pavel
On 9/28/07, Yuri Dolgov <do...@gmail.com> wrote:
>
> Hello,
>
> I've done deeper investigation of the issue. As the matter of fact
> such behavior was due to profiling counters and absence of on stack
> replacement mechanism. I've prepared a patch which fixes the
> problem by replacing counters with nops after profile is ready,
> please see patch JIRA [1]
>
> [1] https://issues.apache.org/jira/browse/HARMONY-4875
>
> Thanks,
> Yuri
>
> On 9/24/07, Yuri Dolgov <do...@gmail.com> wrote:
> >
> > Actually it can, since run() method called only once per thread,
> > so even if run method is very hot it will never be substituted by
> > recompiled one.
> >
> > Thanks,
> > Yuri
> >
> > On 9/24/07, Weldon Washburn <we...@gmail.com> wrote:
> > >
> > > On 9/24/07, Yuri Dolgov <do...@gmail.com> wrote:
> > > > Hello,
> > > >
> > > > I've identified the most probable reason of the issue. It concerns
> to
> > > > gathering profiling information and absence of on stack replacement
> > > > mechanism.
> > >
> > > This is very interesting. Good work! I had no idea "on stack
> > > replacement" code could cause such problems.
> > >
> > >
> > > >
> > > > Currently profiling data is gathered even after it is not
> > > > needed any more for recompilation. And since there is no on stack
> > > > replacement mechanism there is overhead on collection profile data
> > > > till the end of the test. The problem could be solved by switching
> of
> > > > the profile counters after they are not useful.
> > > >
> > > > BTW I'm using pretty fresh version of Harmony (release build) and
> > > > can reproduce Cyang's problem.
> > > >
> > > > Thanks,
> > > > Yuri
> > > >
> > > > On 9/24/07, Weldon Washburn <we...@gmail.com> wrote:
> > > > >
> > > > > Cyang, Yuri,
> > > > >
> > > > > I have committed several threading patches since M2 was released.
> > > > > These threading patches might impact the performance of your test
> > > > > below. Are you using release build or debug build?
> > > > >
> > > > > I noticed your test uses Thread.join(). There are several known
> > > bugs
> > > > > in Thread.join() that we hope to fix shortly. We are working on
> the
> > > > > list of threading problems described in April 2 email called,
> > > > > "[drlvm][threading] a list of design/development issues that need
> > > > > coordination with the [general] "M1" map". In particular we hope
> to
> > > > > have, "Varying Mutexes Protect Different Parts of Thread State,
> Each
> > > > > Thread Has Its Own Mutex" done in the next few months. In other
> > > > > words, before M4 or M5 is released. This project (also called
> > > Thread
> > > > > State Transition Project) intends to fix known Thread.join()
> > > problems.
> > > > >
> > > > > If you have the time, please try again with what is in svn
> HEAD. Or
> > >
> > > > > perhaps wait until M3 is released shortly.
> > > > >
> > > > > On 9/24/07, cyang.cq <cy...@gmail.com> wrote:
> > > > > > Hi, all
> > > > > > The scalability of the program below is surprising on M2.
> > > > > > This program only starts several threads to share the work
> > > > > > of doing a number of additions.
> > > > > >
> > > > > > MT.java:
> > > > > >
> > > > > > public class MT extends Thread{
> > > > > >
> > > > > > static long result = 0;
> > > > > > long len = 0;
> > > > > > public MT(long len){
> > > > > > this.len = len;
> > > > > > }
> > > > > >
> > > > > > public void run(){
> > > > > > long total = 0;
> > > > > > for(long i = 0; i < len; ++i){
> > > > > > total += 1;
> > > > > > }
> > > > > > result = total;
> > > > > > }
> > > > > >
> > > > > > public static void main(String[] args) throws
> > > InterruptedException {
> > > > > > long totalWork = Long.parseLong(args[0]);
> > > > > > int numThreads = Integer.parseInt(args[1]);
> > > > > >
> > > > > > long work = totalWork / numThreads;
> > > > > >
> > > > > > MT[] v = new MT[numThreads];
> > > > > > for(int i = 0; i < numThreads; ++i){
> > > > > > v[i] = new MT(work);
> > > > > > }
> > > > > >
> > > > > > long start = System.currentTimeMillis();
> > > > > > for(int i = 0; i < numThreads; ++i){
> > > > > > v[i].start();
> > > > > > }
> > > > > > for(int i = 0; i < numThreads; ++i){
> > > > > > v[i].join();
> > > > > > }
> > > > > > long dur = System.currentTimeMillis() - start;
> > > > > >
> > > > > > System.out.println("Total time: " + dur);
> > > > > > }
> > > > > >
> > > > > > }
> > > > > >
> > > > > > Run it on 5.0M2:
> > > > > > CMD OUTPUT
> > > > > > java MT 9000000000 1 Total time: 411325
> > > > > > java MT 9000000000 2 Total time: 1052861
> > > > > > java MT 9000000000 4 Total time: 915545
> > > > > > java MT 9000000000 8 Total time: 589672
> > > > > > java MT 9000000000 12 Total time: 678815
> > > > > > java MT 9000000000 16 Total time: 621097
> > > > > >
> > > > > >
> > > > > > Run it on sun jdk 1.5.0_08:
> > > > > > CMD OUTPUT
> > > > > > java MT 9000000000 1 Total time: 10356
> > > > > > java MT 9000000000 2 Total time: 5182
> > > > > > java MT 9000000000 4 Total time: 2601
> > > > > > java MT 9000000000 8 Total time: 1453
> > > > > > java MT 9000000000 12 Total time: 1004
> > > > > > java MT 9000000000 16 Total time: 782
> > > > > >
> > > > > >
> > > > > >
> > > > > > My configuration is:
> > > > > > OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
> > > > > > Kernel 2.6.9-42.ELlargesmp on an x86_64
> > > > > > CPU: 8 X Dual-Core AMD Opteron 2.6G
> > > > > > Mem: 16G
> > > > > > drlvm: Apache Harmony 5.0M2 JRE for 32-bit Linux
> > > > > > for systems with libstdc++.so.5
> > > > > > sun jdk: jdk-1_5_0_08-linux-i586
> > > > > >
> > > > > >
> > > > > > Any suggestions? Have this been fixed already since M2?
> > > > > >
> > > > > > Thanks in advance.
> > > > >
> > > > >
> > > > > --
> > > > > Weldon Washburn
> > > > >
> > > >
> > >
> > >
> > > --
> > > Weldon Washburn
> > >
> >
> >
>
Re: [drlvm][thread]scalability problem
Posted by Yuri Dolgov <do...@gmail.com>.
Hello,
I've done deeper investigation of the issue. As the matter of fact
such behavior was due to profiling counters and absence of on stack
replacement mechanism. I've prepared a patch which fixes the
problem by replacing counters with nops after profile is ready,
please see patch JIRA [1]
[1] https://issues.apache.org/jira/browse/HARMONY-4875
Thanks,
Yuri
On 9/24/07, Yuri Dolgov <do...@gmail.com> wrote:
>
> Actually it can, since run() method called only once per thread,
> so even if run method is very hot it will never be substituted by
> recompiled one.
>
> Thanks,
> Yuri
>
> On 9/24/07, Weldon Washburn <we...@gmail.com> wrote:
> >
> > On 9/24/07, Yuri Dolgov <do...@gmail.com> wrote:
> > > Hello,
> > >
> > > I've identified the most probable reason of the issue. It concerns to
> > > gathering profiling information and absence of on stack replacement
> > > mechanism.
> >
> > This is very interesting. Good work! I had no idea "on stack
> > replacement" code could cause such problems.
> >
> >
> > >
> > > Currently profiling data is gathered even after it is not
> > > needed any more for recompilation. And since there is no on stack
> > > replacement mechanism there is overhead on collection profile data
> > > till the end of the test. The problem could be solved by switching of
> > > the profile counters after they are not useful.
> > >
> > > BTW I'm using pretty fresh version of Harmony (release build) and
> > > can reproduce Cyang's problem.
> > >
> > > Thanks,
> > > Yuri
> > >
> > > On 9/24/07, Weldon Washburn <we...@gmail.com> wrote:
> > > >
> > > > Cyang, Yuri,
> > > >
> > > > I have committed several threading patches since M2 was released.
> > > > These threading patches might impact the performance of your test
> > > > below. Are you using release build or debug build?
> > > >
> > > > I noticed your test uses Thread.join(). There are several known
> > bugs
> > > > in Thread.join() that we hope to fix shortly. We are working on the
> > > > list of threading problems described in April 2 email called,
> > > > "[drlvm][threading] a list of design/development issues that need
> > > > coordination with the [general] "M1" map". In particular we hope to
> > > > have, "Varying Mutexes Protect Different Parts of Thread State, Each
> > > > Thread Has Its Own Mutex" done in the next few months. In other
> > > > words, before M4 or M5 is released. This project (also called
> > Thread
> > > > State Transition Project) intends to fix known Thread.join()
> > problems.
> > > >
> > > > If you have the time, please try again with what is in svn HEAD. Or
> >
> > > > perhaps wait until M3 is released shortly.
> > > >
> > > > On 9/24/07, cyang.cq <cy...@gmail.com> wrote:
> > > > > Hi, all
> > > > > The scalability of the program below is surprising on M2.
> > > > > This program only starts several threads to share the work
> > > > > of doing a number of additions.
> > > > >
> > > > > MT.java:
> > > > >
> > > > > public class MT extends Thread{
> > > > >
> > > > > static long result = 0;
> > > > > long len = 0;
> > > > > public MT(long len){
> > > > > this.len = len;
> > > > > }
> > > > >
> > > > > public void run(){
> > > > > long total = 0;
> > > > > for(long i = 0; i < len; ++i){
> > > > > total += 1;
> > > > > }
> > > > > result = total;
> > > > > }
> > > > >
> > > > > public static void main(String[] args) throws
> > InterruptedException {
> > > > > long totalWork = Long.parseLong(args[0]);
> > > > > int numThreads = Integer.parseInt(args[1]);
> > > > >
> > > > > long work = totalWork / numThreads;
> > > > >
> > > > > MT[] v = new MT[numThreads];
> > > > > for(int i = 0; i < numThreads; ++i){
> > > > > v[i] = new MT(work);
> > > > > }
> > > > >
> > > > > long start = System.currentTimeMillis();
> > > > > for(int i = 0; i < numThreads; ++i){
> > > > > v[i].start();
> > > > > }
> > > > > for(int i = 0; i < numThreads; ++i){
> > > > > v[i].join();
> > > > > }
> > > > > long dur = System.currentTimeMillis() - start;
> > > > >
> > > > > System.out.println("Total time: " + dur);
> > > > > }
> > > > >
> > > > > }
> > > > >
> > > > > Run it on 5.0M2:
> > > > > CMD OUTPUT
> > > > > java MT 9000000000 1 Total time: 411325
> > > > > java MT 9000000000 2 Total time: 1052861
> > > > > java MT 9000000000 4 Total time: 915545
> > > > > java MT 9000000000 8 Total time: 589672
> > > > > java MT 9000000000 12 Total time: 678815
> > > > > java MT 9000000000 16 Total time: 621097
> > > > >
> > > > >
> > > > > Run it on sun jdk 1.5.0_08:
> > > > > CMD OUTPUT
> > > > > java MT 9000000000 1 Total time: 10356
> > > > > java MT 9000000000 2 Total time: 5182
> > > > > java MT 9000000000 4 Total time: 2601
> > > > > java MT 9000000000 8 Total time: 1453
> > > > > java MT 9000000000 12 Total time: 1004
> > > > > java MT 9000000000 16 Total time: 782
> > > > >
> > > > >
> > > > >
> > > > > My configuration is:
> > > > > OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
> > > > > Kernel 2.6.9-42.ELlargesmp on an x86_64
> > > > > CPU: 8 X Dual-Core AMD Opteron 2.6G
> > > > > Mem: 16G
> > > > > drlvm: Apache Harmony 5.0M2 JRE for 32-bit Linux
> > > > > for systems with libstdc++.so.5
> > > > > sun jdk: jdk-1_5_0_08-linux-i586
> > > > >
> > > > >
> > > > > Any suggestions? Have this been fixed already since M2?
> > > > >
> > > > > Thanks in advance.
> > > >
> > > >
> > > > --
> > > > Weldon Washburn
> > > >
> > >
> >
> >
> > --
> > Weldon Washburn
> >
>
>
Re: [drlvm][thread]scalability problem
Posted by Yuri Dolgov <do...@gmail.com>.
Actually it can, since run() method called only once per thread,
so even if run method is very hot it will never be substituted by
recompiled one.
Thanks,
Yuri
On 9/24/07, Weldon Washburn <we...@gmail.com> wrote:
>
> On 9/24/07, Yuri Dolgov <do...@gmail.com> wrote:
> > Hello,
> >
> > I've identified the most probable reason of the issue. It concerns to
> > gathering profiling information and absence of on stack replacement
> > mechanism.
>
> This is very interesting. Good work! I had no idea "on stack
> replacement" code could cause such problems.
>
>
> >
> > Currently profiling data is gathered even after it is not
> > needed any more for recompilation. And since there is no on stack
> > replacement mechanism there is overhead on collection profile data
> > till the end of the test. The problem could be solved by switching of
> > the profile counters after they are not useful.
> >
> > BTW I'm using pretty fresh version of Harmony (release build) and
> > can reproduce Cyang's problem.
> >
> > Thanks,
> > Yuri
> >
> > On 9/24/07, Weldon Washburn <we...@gmail.com> wrote:
> > >
> > > Cyang, Yuri,
> > >
> > > I have committed several threading patches since M2 was released.
> > > These threading patches might impact the performance of your test
> > > below. Are you using release build or debug build?
> > >
> > > I noticed your test uses Thread.join(). There are several known bugs
> > > in Thread.join() that we hope to fix shortly. We are working on the
> > > list of threading problems described in April 2 email called,
> > > "[drlvm][threading] a list of design/development issues that need
> > > coordination with the [general] "M1" map". In particular we hope to
> > > have, "Varying Mutexes Protect Different Parts of Thread State, Each
> > > Thread Has Its Own Mutex" done in the next few months. In other
> > > words, before M4 or M5 is released. This project (also called Thread
> > > State Transition Project) intends to fix known Thread.join() problems.
> > >
> > > If you have the time, please try again with what is in svn HEAD. Or
> > > perhaps wait until M3 is released shortly.
> > >
> > > On 9/24/07, cyang.cq <cy...@gmail.com> wrote:
> > > > Hi, all
> > > > The scalability of the program below is surprising on M2.
> > > > This program only starts several threads to share the work
> > > > of doing a number of additions.
> > > >
> > > > MT.java:
> > > >
> > > > public class MT extends Thread{
> > > >
> > > > static long result = 0;
> > > > long len = 0;
> > > > public MT(long len){
> > > > this.len = len;
> > > > }
> > > >
> > > > public void run(){
> > > > long total = 0;
> > > > for(long i = 0; i < len; ++i){
> > > > total += 1;
> > > > }
> > > > result = total;
> > > > }
> > > >
> > > > public static void main(String[] args) throws InterruptedException
> {
> > > > long totalWork = Long.parseLong(args[0]);
> > > > int numThreads = Integer.parseInt(args[1]);
> > > >
> > > > long work = totalWork / numThreads;
> > > >
> > > > MT[] v = new MT[numThreads];
> > > > for(int i = 0; i < numThreads; ++i){
> > > > v[i] = new MT(work);
> > > > }
> > > >
> > > > long start = System.currentTimeMillis();
> > > > for(int i = 0; i < numThreads; ++i){
> > > > v[i].start();
> > > > }
> > > > for(int i = 0; i < numThreads; ++i){
> > > > v[i].join();
> > > > }
> > > > long dur = System.currentTimeMillis() - start;
> > > >
> > > > System.out.println("Total time: " + dur);
> > > > }
> > > >
> > > > }
> > > >
> > > > Run it on 5.0M2:
> > > > CMD OUTPUT
> > > > java MT 9000000000 1 Total time: 411325
> > > > java MT 9000000000 2 Total time: 1052861
> > > > java MT 9000000000 4 Total time: 915545
> > > > java MT 9000000000 8 Total time: 589672
> > > > java MT 9000000000 12 Total time: 678815
> > > > java MT 9000000000 16 Total time: 621097
> > > >
> > > >
> > > > Run it on sun jdk 1.5.0_08:
> > > > CMD OUTPUT
> > > > java MT 9000000000 1 Total time: 10356
> > > > java MT 9000000000 2 Total time: 5182
> > > > java MT 9000000000 4 Total time: 2601
> > > > java MT 9000000000 8 Total time: 1453
> > > > java MT 9000000000 12 Total time: 1004
> > > > java MT 9000000000 16 Total time: 782
> > > >
> > > >
> > > >
> > > > My configuration is:
> > > > OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
> > > > Kernel 2.6.9-42.ELlargesmp on an x86_64
> > > > CPU: 8 X Dual-Core AMD Opteron 2.6G
> > > > Mem: 16G
> > > > drlvm: Apache Harmony 5.0M2 JRE for 32-bit Linux
> > > > for systems with libstdc++.so.5
> > > > sun jdk: jdk-1_5_0_08-linux-i586
> > > >
> > > >
> > > > Any suggestions? Have this been fixed already since M2?
> > > >
> > > > Thanks in advance.
> > >
> > >
> > > --
> > > Weldon Washburn
> > >
> >
>
>
> --
> Weldon Washburn
>
Re: [drlvm][thread]scalability problem
Posted by Weldon Washburn <we...@gmail.com>.
On 9/24/07, Yuri Dolgov <do...@gmail.com> wrote:
> Hello,
>
> I've identified the most probable reason of the issue. It concerns to
> gathering profiling information and absence of on stack replacement
> mechanism.
This is very interesting. Good work! I had no idea "on stack
replacement" code could cause such problems.
>
> Currently profiling data is gathered even after it is not
> needed any more for recompilation. And since there is no on stack
> replacement mechanism there is overhead on collection profile data
> till the end of the test. The problem could be solved by switching of
> the profile counters after they are not useful.
>
> BTW I'm using pretty fresh version of Harmony (release build) and
> can reproduce Cyang's problem.
>
> Thanks,
> Yuri
>
> On 9/24/07, Weldon Washburn <we...@gmail.com> wrote:
> >
> > Cyang, Yuri,
> >
> > I have committed several threading patches since M2 was released.
> > These threading patches might impact the performance of your test
> > below. Are you using release build or debug build?
> >
> > I noticed your test uses Thread.join(). There are several known bugs
> > in Thread.join() that we hope to fix shortly. We are working on the
> > list of threading problems described in April 2 email called,
> > "[drlvm][threading] a list of design/development issues that need
> > coordination with the [general] "M1" map". In particular we hope to
> > have, "Varying Mutexes Protect Different Parts of Thread State, Each
> > Thread Has Its Own Mutex" done in the next few months. In other
> > words, before M4 or M5 is released. This project (also called Thread
> > State Transition Project) intends to fix known Thread.join() problems.
> >
> > If you have the time, please try again with what is in svn HEAD. Or
> > perhaps wait until M3 is released shortly.
> >
> > On 9/24/07, cyang.cq <cy...@gmail.com> wrote:
> > > Hi, all
> > > The scalability of the program below is surprising on M2.
> > > This program only starts several threads to share the work
> > > of doing a number of additions.
> > >
> > > MT.java:
> > >
> > > public class MT extends Thread{
> > >
> > > static long result = 0;
> > > long len = 0;
> > > public MT(long len){
> > > this.len = len;
> > > }
> > >
> > > public void run(){
> > > long total = 0;
> > > for(long i = 0; i < len; ++i){
> > > total += 1;
> > > }
> > > result = total;
> > > }
> > >
> > > public static void main(String[] args) throws InterruptedException {
> > > long totalWork = Long.parseLong(args[0]);
> > > int numThreads = Integer.parseInt(args[1]);
> > >
> > > long work = totalWork / numThreads;
> > >
> > > MT[] v = new MT[numThreads];
> > > for(int i = 0; i < numThreads; ++i){
> > > v[i] = new MT(work);
> > > }
> > >
> > > long start = System.currentTimeMillis();
> > > for(int i = 0; i < numThreads; ++i){
> > > v[i].start();
> > > }
> > > for(int i = 0; i < numThreads; ++i){
> > > v[i].join();
> > > }
> > > long dur = System.currentTimeMillis() - start;
> > >
> > > System.out.println("Total time: " + dur);
> > > }
> > >
> > > }
> > >
> > > Run it on 5.0M2:
> > > CMD OUTPUT
> > > java MT 9000000000 1 Total time: 411325
> > > java MT 9000000000 2 Total time: 1052861
> > > java MT 9000000000 4 Total time: 915545
> > > java MT 9000000000 8 Total time: 589672
> > > java MT 9000000000 12 Total time: 678815
> > > java MT 9000000000 16 Total time: 621097
> > >
> > >
> > > Run it on sun jdk 1.5.0_08:
> > > CMD OUTPUT
> > > java MT 9000000000 1 Total time: 10356
> > > java MT 9000000000 2 Total time: 5182
> > > java MT 9000000000 4 Total time: 2601
> > > java MT 9000000000 8 Total time: 1453
> > > java MT 9000000000 12 Total time: 1004
> > > java MT 9000000000 16 Total time: 782
> > >
> > >
> > >
> > > My configuration is:
> > > OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
> > > Kernel 2.6.9-42.ELlargesmp on an x86_64
> > > CPU: 8 X Dual-Core AMD Opteron 2.6G
> > > Mem: 16G
> > > drlvm: Apache Harmony 5.0M2 JRE for 32-bit Linux
> > > for systems with libstdc++.so.5
> > > sun jdk: jdk-1_5_0_08-linux-i586
> > >
> > >
> > > Any suggestions? Have this been fixed already since M2?
> > >
> > > Thanks in advance.
> >
> >
> > --
> > Weldon Washburn
> >
>
--
Weldon Washburn
Re: [drlvm][thread]scalability problem
Posted by Yuri Dolgov <do...@gmail.com>.
Hello,
I've identified the most probable reason of the issue. It concerns to
gathering profiling information and absence of on stack replacement
mechanism.
Currently profiling data is gathered even after it is not
needed any more for recompilation. And since there is no on stack
replacement mechanism there is overhead on collection profile data
till the end of the test. The problem could be solved by switching of
the profile counters after they are not useful.
BTW I'm using pretty fresh version of Harmony (release build) and
can reproduce Cyang's problem.
Thanks,
Yuri
On 9/24/07, Weldon Washburn <we...@gmail.com> wrote:
>
> Cyang, Yuri,
>
> I have committed several threading patches since M2 was released.
> These threading patches might impact the performance of your test
> below. Are you using release build or debug build?
>
> I noticed your test uses Thread.join(). There are several known bugs
> in Thread.join() that we hope to fix shortly. We are working on the
> list of threading problems described in April 2 email called,
> "[drlvm][threading] a list of design/development issues that need
> coordination with the [general] "M1" map". In particular we hope to
> have, "Varying Mutexes Protect Different Parts of Thread State, Each
> Thread Has Its Own Mutex" done in the next few months. In other
> words, before M4 or M5 is released. This project (also called Thread
> State Transition Project) intends to fix known Thread.join() problems.
>
> If you have the time, please try again with what is in svn HEAD. Or
> perhaps wait until M3 is released shortly.
>
> On 9/24/07, cyang.cq <cy...@gmail.com> wrote:
> > Hi, all
> > The scalability of the program below is surprising on M2.
> > This program only starts several threads to share the work
> > of doing a number of additions.
> >
> > MT.java:
> >
> > public class MT extends Thread{
> >
> > static long result = 0;
> > long len = 0;
> > public MT(long len){
> > this.len = len;
> > }
> >
> > public void run(){
> > long total = 0;
> > for(long i = 0; i < len; ++i){
> > total += 1;
> > }
> > result = total;
> > }
> >
> > public static void main(String[] args) throws InterruptedException {
> > long totalWork = Long.parseLong(args[0]);
> > int numThreads = Integer.parseInt(args[1]);
> >
> > long work = totalWork / numThreads;
> >
> > MT[] v = new MT[numThreads];
> > for(int i = 0; i < numThreads; ++i){
> > v[i] = new MT(work);
> > }
> >
> > long start = System.currentTimeMillis();
> > for(int i = 0; i < numThreads; ++i){
> > v[i].start();
> > }
> > for(int i = 0; i < numThreads; ++i){
> > v[i].join();
> > }
> > long dur = System.currentTimeMillis() - start;
> >
> > System.out.println("Total time: " + dur);
> > }
> >
> > }
> >
> > Run it on 5.0M2:
> > CMD OUTPUT
> > java MT 9000000000 1 Total time: 411325
> > java MT 9000000000 2 Total time: 1052861
> > java MT 9000000000 4 Total time: 915545
> > java MT 9000000000 8 Total time: 589672
> > java MT 9000000000 12 Total time: 678815
> > java MT 9000000000 16 Total time: 621097
> >
> >
> > Run it on sun jdk 1.5.0_08:
> > CMD OUTPUT
> > java MT 9000000000 1 Total time: 10356
> > java MT 9000000000 2 Total time: 5182
> > java MT 9000000000 4 Total time: 2601
> > java MT 9000000000 8 Total time: 1453
> > java MT 9000000000 12 Total time: 1004
> > java MT 9000000000 16 Total time: 782
> >
> >
> >
> > My configuration is:
> > OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
> > Kernel 2.6.9-42.ELlargesmp on an x86_64
> > CPU: 8 X Dual-Core AMD Opteron 2.6G
> > Mem: 16G
> > drlvm: Apache Harmony 5.0M2 JRE for 32-bit Linux
> > for systems with libstdc++.so.5
> > sun jdk: jdk-1_5_0_08-linux-i586
> >
> >
> > Any suggestions? Have this been fixed already since M2?
> >
> > Thanks in advance.
>
>
> --
> Weldon Washburn
>
Re: [drlvm][thread]scalability problem
Posted by Weldon Washburn <we...@gmail.com>.
Cyang, Yuri,
I have committed several threading patches since M2 was released.
These threading patches might impact the performance of your test
below. Are you using release build or debug build?
I noticed your test uses Thread.join(). There are several known bugs
in Thread.join() that we hope to fix shortly. We are working on the
list of threading problems described in April 2 email called,
"[drlvm][threading] a list of design/development issues that need
coordination with the [general] "M1" map". In particular we hope to
have, "Varying Mutexes Protect Different Parts of Thread State, Each
Thread Has Its Own Mutex" done in the next few months. In other
words, before M4 or M5 is released. This project (also called Thread
State Transition Project) intends to fix known Thread.join() problems.
If you have the time, please try again with what is in svn HEAD. Or
perhaps wait until M3 is released shortly.
On 9/24/07, cyang.cq <cy...@gmail.com> wrote:
> Hi, all
> The scalability of the program below is surprising on M2.
> This program only starts several threads to share the work
> of doing a number of additions.
>
> MT.java:
>
> public class MT extends Thread{
>
> static long result = 0;
> long len = 0;
> public MT(long len){
> this.len = len;
> }
>
> public void run(){
> long total = 0;
> for(long i = 0; i < len; ++i){
> total += 1;
> }
> result = total;
> }
>
> public static void main(String[] args) throws InterruptedException {
> long totalWork = Long.parseLong(args[0]);
> int numThreads = Integer.parseInt(args[1]);
>
> long work = totalWork / numThreads;
>
> MT[] v = new MT[numThreads];
> for(int i = 0; i < numThreads; ++i){
> v[i] = new MT(work);
> }
>
> long start = System.currentTimeMillis();
> for(int i = 0; i < numThreads; ++i){
> v[i].start();
> }
> for(int i = 0; i < numThreads; ++i){
> v[i].join();
> }
> long dur = System.currentTimeMillis() - start;
>
> System.out.println("Total time: " + dur);
> }
>
> }
>
> Run it on 5.0M2:
> CMD OUTPUT
> java MT 9000000000 1 Total time: 411325
> java MT 9000000000 2 Total time: 1052861
> java MT 9000000000 4 Total time: 915545
> java MT 9000000000 8 Total time: 589672
> java MT 9000000000 12 Total time: 678815
> java MT 9000000000 16 Total time: 621097
>
>
> Run it on sun jdk 1.5.0_08:
> CMD OUTPUT
> java MT 9000000000 1 Total time: 10356
> java MT 9000000000 2 Total time: 5182
> java MT 9000000000 4 Total time: 2601
> java MT 9000000000 8 Total time: 1453
> java MT 9000000000 12 Total time: 1004
> java MT 9000000000 16 Total time: 782
>
>
>
> My configuration is:
> OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
> Kernel 2.6.9-42.ELlargesmp on an x86_64
> CPU: 8 X Dual-Core AMD Opteron 2.6G
> Mem: 16G
> drlvm: Apache Harmony 5.0M2 JRE for 32-bit Linux
> for systems with libstdc++.so.5
> sun jdk: jdk-1_5_0_08-linux-i586
>
>
> Any suggestions? Have this been fixed already since M2?
>
> Thanks in advance.
--
Weldon Washburn