The result of the test with the patch applied looks great! Thanks, Yuri. Pavel
On 9/28/07, Yuri Dolgov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > On 9/24/07, Yuri Dolgov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > > > > > >
