gmane.comp.java.harmony.devel

Re: [general] Ja.NET SE OSS Project

Xiao-Feng Li — 2008-12-03T14:16:19

I see. Thanks for the explanation. Really interesting! Will have a look. Thanks, xiaofeng

Re: [general] Ja.NET SE OSS Project

Alexey Petrenko — 2008-12-03T13:30:42

Sounds really interesting! :) 2008/12/3 Dave janetdev.org>:

Re: [general] Ja.NET SE OSS Project

Dave — 2008-12-03T13:07:26

Hi Xiao-Feng, Yes, the compiler generates .NET CLR byte code. Of course it is still also able to generate java byte code as well. A Ja.NET SE distribution includes both the Harmony JVM(i.e. DRLVM) as well as a Ja.NET SE VM adapter that I have developed. The adapter is a small layer that sits between the compiled .NET version of the class libraries and the .NET CLR/Framework. It deals with the differences between the two runtimes. Using options to the Harmony Java launcher you pick what VM (DRLVM or CLR) you want started. By default, with a Ja.NET SE distribution, the default VM loaded is the Ja.NET VM adapter/CLR instead of the DRLVM. You can still load the DRLVM by simply invoking the launcher with: "java -vmdir:drlvm .....". When compiling code, the Ja.NET SE compiler, by default, will generate CLR CIL in PE files (i.e. .NET Assemblies), instead of Java .class files. I provide a tool called "bam", that can then be used to "jar" up the created assemblies into a larger unit (i.e .NET A

Re: [site] Russian website

Sian January — 2008-12-03T09:32:15

Thanks very much Alexei. 2008/12/2 Alexei Fedotov gmail.com>:

Re: svn commit: r721444 - in /harmony/enhanced/classlib/trunk/modules/luni/src/main: java/java/net/ java/org/apache/harmony/luni/net/ java/org/apache/harmony/luni/platform/ native/luni/shared/

Tim Ellison — 2008-12-03T09:12:38

Thanks Chunrong. Fixed < at > r722815. Regards, Tim chunrong lai wrote:

Re: svn commit: r721444 - in /harmony/enhanced/classlib/trunk/modules/luni/src/main: java/java/net/ java/org/apache/harmony/luni/net/ java/org/apache/harmony/luni/platform/ native/luni/shared/

chunrong lai — 2008-12-03T05:54:17

It is a note that multiple classlib tests fail in Linux platform with this commit, according to the integrity results. Below is the stacktrace. [java] [junit] Uncaught exception in Thread-18: [java] [junit] java.lang.UnsatisfiedLinkError: Cannot load native org/apache/harmony/luni/platform/OSNetworkSystem.write(Ljava/io/FileDescriptor;[BII)I [java] [junit] at org.apache.harmony.luni.net.PlainSocketImpl.write(PlainSocketImpl.java:554) [java] [junit] at org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:50) [java] [junit] at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.close(SSLSocketImpl.java:507) [java] [junit] at org.apache.harmony.xnet.provider.jsse.SSLSocketFunctionalTest$2.run(SSLSocketFunctionalTest.java:322) [java] [junit] Caused by: java.lang.UnsatisfiedLinkError: org/apache/harmony/luni/platform/OSNetworkSystem.write(Ljava/io/FileDescriptor;[BII)I [java] [junit] at org.apache.harmony.luni.net.P

Re: [general] Ja.NET SE OSS Project

Tony Wu — 2008-12-03T03:41:57

+1 Dave, Welcome to Harmony ;-)

Re: [general] Ja.NET SE OSS Project

Xiao-Feng Li — 2008-12-03T01:28:04

This is cool! Dave, what's the technology approach you are taking for Ja.NET JDK? Does it compile Java code into CLR bytecode running on Mono? I can't find any document in your website about it. Thanks, xiaofeng

Re: [general] Ja.NET SE OSS Project

Tim Ellison — 2008-12-02T20:53:18

That sounds cool Dave -- good luck with the project, and be sure to pass on any bugs/successes you have with the Harmony code. Regards, Tim Dave wrote:

[general] Ja.NET SE OSS Project

Dave — 2008-12-02T18:35:04

Hi All, I just wanted to take a minute and bring your attention to an OSS project, based on Harmony, I recently started .... Ja.NET (www.janetdev.org). I am building a Java 5 JDK for .NET (i.e. Ja.NET SE), and I am using Harmony, along with other open source software (e.g. Eclipse compiler, Mono, etc.) as the basis for the work. The goal of the project is to create the development tools and libraries that will enable Java to become a "first class" development and runtime environment for .NET. The Ja.NET SE JDK project is the first thing I have kicked off. The hope is, at some point in the "very near future", :-), the Ja.NET SE JDK will give developers all the Java development tools they need to develop software in Java for the .NET platform. For example, the Java development tools would enable someone to take existing Java source code (e.g. Ant, Xerces, Eclipse, etc.) and easily build it, enhance it with new .NET specific features, integrate it with other .NET code and libraries (e.g. C#, VB.

Re: [site] Russian website

Alexei Fedotov — 2008-12-02T17:48:25

Sian, thanks. I've committed the patch. On Tue, Dec 2, 2008 at 5:50 PM, Sian January googlemail.com> wrote:

Re: [site] Russian website

Sian January — 2008-12-02T14:50:58

Thanks Aleksey. Is there a Russian-speaking committer willing to review the patch and check it in? 2008/12/2 Aleksey Shipilev gmail.com>:

Re: [drlvm][jitrino][test] Large contribution of reliability test cases for DRLVM+Dacapo

Egor Pasko — 2008-12-02T14:47:14

this is what I call one by one :) please, do not take the Kohonen net, it is hard to debug, I am not a machine learning expert, but do not take Kohonen net :)

Re: [drlvm][jitrino][test] Large contribution of reliability test cases for DRLVM+Dacapo

Aleksey Shipilev — 2008-12-02T14:36:55

Hi, Egor! On Tue, Dec 2, 2008 at 5:16 PM, Egor Pasko gmail.com> wrote: If the gun's license was granted to Schrödinger... :) Of course not! My original thought was like following: automatize the check process first, then: a. Slide to the next bug. b. Reproduce it: c1. Is this a bug? Mark it with the assert() or something. c2. Is this crash "normal"? Throw some meaningful message. d. Re-run all tests and see which fall into new category, mark all emconfs as faulty within this category. e. Exclude new category bugs from the pool and go to (a). It's more like Sieve of Eratosthenes :) Yeah! Glad we think in one direction -- try to cluster the bugs. I was solving the similar issue in my school project with Kohonen's maps, hopefully I'll reproduce the project some day for this occasion. We can also look into Matlab ;) Anyway, this sounds like a good student project "just-for-fun". Thanks, Aleksey.

Re: Fwd: [jira] Created: (HARMONY-6007) [drlvm][jit][abcd] classic abcd pass fixes

Egor Pasko — 2008-12-02T14:34:58

our pi nodes are richer than in the original paper, they contain all upper- and lower- related information. That is why I said that a single e-SSA would be enough. okay, I cannot say I understand this, sorry :) I'll manage to get some time for this task, I promise. on first implementation we checked BidirectionalBubbleSort with the current ABCD. It removed all checks. IMHO, this is a good argument to prove that the issue is fixable without introducing principially new concepts.

Re: [site] Russian website

Aleksey Shipilev — 2008-12-02T14:20:20

Hi, Sian, pick up some RusSian at https://issues.apache.org/jira/browse/HARMONY-6031. The patch should be in UTF-8 and should be applied without clashes. Thanks, Aleksey. [1] On Tue, Dec 2, 2008 at 4:41 PM, Aleksey Shipilev gmail.com> wrote:

Re: [drlvm][jitrino][test] Large contribution of reliability test cases for DRLVM+Dacapo

Egor Pasko — 2008-12-02T14:16:26

offense? why? :) I really enjoy the conversation. Aleksey, is there a combined solution, where I push the red button, which makes the silver bullet to fire? :) Your argument about these being 'near' most effective configurations is interesting indeed. And result is interesting overall. True. Big respect, etc. My concern is: is it effective to look through configurations one by one to find issues in this compiler? Lots of false-positives really worry me. Seems like without traversing 10s or even 100s of emconfs by hand it is hard to find something valuable. For Jikes the situation might be completely different, Jikes is not an argument here :) However, there is one idea .. why are you classifying the configurations based only by end result status? clusters are obviously too big. I would also take the configurations as a parameter for clustering failures. Yes, you'll need a fair amount of machine learning efforts to cluster them. But that may pay off really well. Looking into trained model BDD could give

Re: [site] Russian website

Aleksey Shipilev — 2008-12-02T13:41:32

Hi, Sian! Public SVN URL is https://svn.apache.org/repos/asf/harmony/standard/site . I'll update it by the end of the day. Thanks, Aleksey. On Mon, Dec 1, 2008 at 7:49 PM, Sian January googlemail.com> wrote:

Re: [drlvm][jitrino][test] Large contribution of reliability test cases for DRLVM+Dacapo

Ian Rogers — 2008-12-02T13:10:53

2008/12/2 Aleksey Shipilev gmail.com>: A particular tale of sorrow from Jikes RVM was that a bug crept into our SSA code due to naive loop unrolling masking the bug. When we later experimented with no loop unrolling, to benefit loop versioning, we found SSA was broken. The bug is sufficiently subtle that we haven't yet been able to create a unit test. We're slowly introducing optimizations back into our O2 set once we're confident they are robust. The nice thing is this gives us scope to improve our performance. Regards, Ian

Re: [drlvm][jitrino][test] Large contribution of reliability test cases for DRLVM+Dacapo

Aleksey Shipilev — 2008-12-02T12:23:45

Hi, Egor! Your thoughts are truly pessimistic like everyone who develop at least one compiler has. Of course, there's no silver bullet, e.g. there's no such system where you can press the big red button and the system will say where're the bugs :) The whole thing about that fuzzy testing is: a. Yes, there can be false-positives. b. Yes, there can be plenty of false-positives. c. Somewhere behind the stack there are real issues covered. The problem is, no matter what we are thinking about automated testing of compiler, any testing results would produce nearly the same amount of garbage above the real issues. You'll make the random search, you'll have the whole search space to track: 200 boolean params effectively produce 2^200 possible tuples. What these results are for, they are more focused on near-optimal configurations and so we needn't to scratch our heads on whether we should take care of configuration that lies far away from optimal. Again, there can be lots of garbage in those tests, but 5.400+

[classlib][luni] BufferedInputStream changes (was: Re: svn commit: r721075 - in /harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/io/BufferedInputStream.java test/api/common/org/apache/harmony/luni/tests/java/io/BufferedInputStreamTest.java)

Tim Ellison — 2008-12-02T12:19:51

The problem is that that the patch I uploaded is not complete. It was there for discussion about the direction I was taking. To complete it will require a new lock to avoid a race when closing the stream and refilling it on different threads. All these changes /may/ be worse than using a synchronized close. Regards, Tim ng_Class\nTest_java_lang_ClassCastException\nTest_java_lang_ClassCircularityError\nTest_java_lang_ClassFormatError\nTest_java_lang_ClassLoader\nTest_java_lang fFoundError\nTest_java_lang_NoSuchFieldError\nTest_java_lang_NoSuchMethodError\nTest_java_lang_NullPointerException\nTest_java_lang_Number\nTest_java_lang_NumberFormatException\nTest_java_l a tagramSocketImpl\nTest_java_net_InetAddress\nTest_java_net_NoRouteToHostException\nTest_java_net_PlainDatagramSocketImpl\nTest_java_net_PlainSocketImpl\nTest_java_net_Socket\nTest_java_net_ S ng_Class\nTest_java_lang_ClassCastException\nTest_java_lang_ClassCircularityError\nTest_java_lang_ClassFormatError\nTest_java_lang_ClassLoader\nTest