harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Novodvorsky (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4036) [drlvm][thread] significant performance degradation (scalability problem), in particular on DaCapo:xalan (2x)
Date Tue, 19 Jun 2007 11:10:26 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506120
] 

Peter Novodvorsky commented on HARMONY-4036:
--------------------------------------------

1). I didn't see where GC use the same functionality. When GC would want to use rwlocks we
can export them, right now we can't after feature freeze extend the interface of TM.

2). I didn't see any performance degradation without SPIN_COUNT changing.



> [drlvm][thread] significant performance degradation (scalability problem), in particular
on DaCapo:xalan (2x)
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-4036
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4036
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Evgeniya Maenkova
>            Assignee: weldon washburn
>            Priority: Critical
>         Attachments: reader_writer_lock_table.patch, reader_writer_lock_table_3.patch,
readers_writers_lock_table_2.patch, readers_writers_locktable_untabify_indent.patch, ThreadTest.java
>
>
> Significant performance degradation has been discovered. This happened between r541650-r541654.
More likely, this is r541653 (H-2742).
> 2x times degradation on Dacapo::xalan.
> I wrote the simple reproducer (see please below and to be attached) and got the following
data on a machine with 4 logical processors:
>                        1 thread     4 thread   4thr/1thr  
> 24-May          2828           9594         3.392504  (r541650)
> 31-May          2891           271394     93.87548 (r541654).
>  
> On r541654 version the system time increases significantly, cpu utilization is about
28% only. Unlike r541654 version, where things are going well (cpu utilization ~80%).
> Scale factor changed from 3.39 to 93.88.
> The test is:
> import java.io.IOException;
> public class ThreadTest extends Thread {
> 	static private void doComputing(long n)
> 			throws IOException {
> 		int res = 1;
> 		for (int i = 1; i < 1000; i ++) {
> 			res *=i;
> 		}
> 	}
> 	public void doIt() throws Exception {
> 		for (int j = 0; j < 500000; j ++) {			
> 		    doComputing(getBD());			  
> 		}
> 	}
> 	
> 	static long bd = 0;
> 	
> 	static synchronized long getBD() {
> 		bd ++;		
> 		if (bd == Long.MAX_VALUE) {
> 			bd = 1;
> 		}
> 		return bd;
> 	}
> 	
> 	public void run() {
> 		for (int i = 0; i < loops; i ++) {
> 			System.out.println(i);
> 			try {
> 			   doIt();
> 			} catch (Exception e) {
> 				e.printStackTrace();
> 			}					
> 		}
> 	}
> 	public static int loops;
> 	public static void main(String[] args) throws Exception{
> 		loops = Integer.parseInt(args[0]);		
> 		int thrNum = Integer.parseInt(args[1]);
> 		long start = System.currentTimeMillis();
> 		Thread[] threads = new Thread[thrNum];
> 		for (int i = 0;  i < thrNum; i ++) {
> 		    threads[i] = new ThreadTest();
> 		    threads[i].start();
> 		}
> 		
>         for (int i = 0;  i < thrNum; i ++) {
> 			threads[i].join();
> 		}
> 		System.out.println("result: " + (System.currentTimeMillis() - start));
> 	}
> }
> To run it: java ThreadTest <loops>  <threads number>
> (For instance, "java  -Xem:server -XX:vm.dlls=gc_cc.dll -Xmx900m -Xms900m ThreadTest
5 4" or "java -Xem:server -XX:vm.dlls=gc_cc.dll -Xmx900m -Xms900mThreadTest 5 1". These ones
are used by me to create the table mentioned above).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message