harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [drlvm][thread]scalability problem
Date Fri, 28 Sep 2007 17:42:17 GMT
The result of the test with the patch applied looks great! Thanks, Yuri.

Pavel


On 9/28/07, Yuri Dolgov <dolgov.g.yuri@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 <dolgov.g.yuri@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 <weldonwjw@gmail.com> wrote:
> > >
> > > On 9/24/07, Yuri Dolgov <dolgov.g.yuri@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 <weldonwjw@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 <cyang.cq@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
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message