Re: [Ikvm-developers] IKVM Compiled DLL and multithreading
Brought to you by:
jfrijters
|
From: Jeroen F. <je...@su...> - 2014-04-23 11:02:02
|
Hi, These are both caused by object allocation, so I assume the GC is causing the blocking. Try running with server GC<http://msdn.microsoft.com/en-us/library/ms229357(v=vs.110).aspx>. Regards, Jeroen From: Micle, Florin [mailto:Mi...@ad...] Sent: Wednesday, April 23, 2014 0:05 To: Jeroen Frijters; ikv...@li... Subject: RE: IKVM Compiled DLL and multithreading And here are some examples of contention call stacks reported by Visual Studio: Blocked 4 msec: clr.dll java.lang.AbstractStringBuilder..ctor(int32) java.lang.StringBuilder..ctor() MyMath.DoSomeMath(class java.util.Map) MyMath.run() Blocked 4 msec: System.String.CtorCharArrayStartLength(char[], int32, int32) Java.lang.StringBuild.toString() MyMath.DoSomeMath(class java.util.Map) MyMath.run() From: Micle, Florin Sent: Tuesday, April 22, 2014 4:54 PM To: Micle, Florin; Jeroen Frijters; ikv...@li...<mailto:ikv...@li...> Subject: RE: IKVM Compiled DLL and multithreading I wrote a simple class with one method that adds the elements of a map 10,000 times: public class MyMath implements Runnable { public void run() { HashMap data = new HashMap(); for (int i = 0; i < 10000; ++i) { data.put("element" + i, i); } DoSomeMath(data); } public int DoSomeMath(Map data) { int sum = 0; for (int i = 0; i < 10000; ++i) { for (int j = 0; j < data.size(); ++j) { String index = "element" + j; Integer value = (Integer)data.get(index); sum += value; } } return sum; } } I made a jar with this file and compiled it into a DLL using IKVMC. I added this DLL as a reference to a .NET/C# program and call this method (MyMath.DoSomeMath()) from my C# program, on multiple threads. The more threads I add, the more each thread's performance degrades, because of contentions to the clr.dll. I believe this is caused by the OpenJDK implementation of the Map/HashMap class, because I can't reproduce the same behavior with simple types. The more complex objects the code uses, the higher the number of contentions to the clr.dll. I also cannot reproduce the contentions if I use .NET/C# only objects. I'm willing to share more code and/or try any suggestions into how I could resolve this problem. Here is how my C# program looks like: public static void Main() { _start = DateTime.Now; var m1 = new MyMath(); var m2 = new MyMath(); var m3 = new MyMath(); var m4 = new MyMath(); var t1 = Task.Factory.StartNew(m1.run); var t2 = Task.Factory.StartNew(m2.run); var t3 = Task.Factory.StartNew(m3.run); var t4 = Task.Factory.StartNew(m4.run); Task.WaitAll(new Task[] { t1, t2, t3, t4 }); } The java code doing the same thing looks like this: Thread thread1 = new Thread(new MyMath()); thread1.start(); Thread thread2 = new Thread(new MyMath()); thread2.start(); Thread thread3 = new Thread(new MyMath()); thread3.start(); Thread thread4 = new Thread(new MyMath()); thread4.start(); thread1.join(); thread2.join(); thread3.join(); thread4.join(); Any insight/suggestions will be highly appreciated. Best Regards, Florin Micle From: Micle, Florin [mailto:Mi...@ad...] Sent: Tuesday, April 15, 2014 6:29 PM To: Jeroen Frijters; ikv...@li...<mailto:ikv...@li...> Subject: Re: [Ikvm-developers] IKVM Compiled DLL and multithreading Is the access to the clr.dll from IKVM synchronized? It looks like most of my contentions are in the clr.dll, calls coming from IKVM.OpenJDK.Core.dll. Is the implementation of the OpenJDK synchronized so that only one thread at a time can actually call into the clr.dll? That would basically explain the performance degradation I see with the increased number of threads. I wrote some simple app that starts a few threads that do a lot of computations and nested loops and they behave as expected. In fact the performance explorer in Visual Studio reports 0 contentions, although obviously clr.dll is heavily used. Thanks in advance, Florin From: Jeroen Frijters [mailto:je...@su...] Sent: Thursday, April 10, 2014 11:04 AM To: Micle, Florin; ikv...@li...<mailto:ikv...@li...> Subject: RE: IKVM Compiled DLL and multithreading Without actual code I can only guess, but it could be related to synchronization. In HotSpot, synchronization is heavily optimized (because of the brain damaged design of the early days Java collection classes) and .NET synchronization is not very optimized at all. Regards, Jeroen From: Micle, Florin [mailto:Mi...@ad...] Sent: Thursday, April 10, 2014 17:56 To: ikv...@li...<mailto:ikv...@li...> Subject: [Ikvm-developers] IKVM Compiled DLL and multithreading Hello everyone, I used IKVMC to compile a jar into a .NET DLL. The jar does some intensive math computations, maxing out the CPU core on which the thread runs. In Java each thread will max out at 12.5% CPU (because I have 8 cores, 100% / 8 = 12.5% max CPU per thread). It works fine if I have one thread or 6. If I use this in the .NET world, one thread will use 12.5% CPU, 2 threads will use about 11% CPU each, 3 threads about 9%, 4 threads about 7% each. The performance of each thread degrades considerably the more threads I have. Doesn't happen if I use the jar from a java app. It feels like it's something deep inside the compiled .NET DLL there is some serialization that occurs, some resource contention... no idea... I tried setting the apartment option to MTA when compiling the jar and it didn't make a difference. Any suggestions would be highly appreciated. Best Regards, Florin Micle |