Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 -Stepan. On 10/21/06, Geir Magnusson Jr. wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] Seems like too many classes loaded
On the 0x20B day of Apache Harmony Armand Navabi wrote:
> I am trying to become more familiar with the jit code. I ran the
> following to see what all was compiled when running Hello World.
> "java -Xtrace:compile Hello". I was very surprised to see the number of
> methods that seem to be loaded. I think there are about 1079 methods
> that get compiled for Hello World.
>
> Does harmony just load all the classes in the classlib and compile every
> method? If not, then why would there be so many methods compiled for a
> simple hello world program?
my 2c:
first time methods are compiled "just before execution". So, you have
to execute a method in your app to see it compiled.
> Right now I am trying to write a simple profiling tool that counts the
> number of certain instructions in a program for a given input (i.e. I
> want to run the program, and for every instruction that ends up running,
> collect information). So, since it seems that the jit not only compiles
> every instruction in the program (not only the ones that end up
> running), but also a bunch of other classes, I thought perhaps I would
> be more interested in the interpreter.
Do you mean bytecode instructions? or CPU instructions? For bytecode
you better use the interpreter. For IA-32 we have a special profiling
utility in JIT CG ("iprof") that allows to count how many instructions
of a certain kind were executed, what are the hottest basicblocks,
etc. Feel free to ask on "iprof" in the mailing list. (I think, "we
should document this" :P, but it is not the first priority)
> Running "java -Xint -Xtrace:interpreter Hello" then also gave me way
> more output then I expected. For example
>
> ...
> interpreter: java/lang/String indexOf(II)I
> interpreter: java/lang/String startsWith(Ljava/lang/String;)Z
> interpreter: java/lang/String startsWith(Ljava/lang/String;I)Z
> interpreter: java/lang/String regionMatches(ILjava/lang/String;II)Z
> interpreter: java/net/URI
> access$1002(Ljava/net/URI;Ljava/lang/String;)Ljava/lang/String;
> interpreter: java/net/URI access$1000(Ljava/net/URI;)Ljava/lang/String;
> interpreter: java/net/URI$Helper
> validatePath(Ljava/lang/String;Ljava/lang/String;I)V
> interpreter: java/net/URIEncoderDecoder
> validate(Ljava/lang/String;Ljava/lang/String;)V
> interpreter: java/lang/String length()I
> interpreter: java/lang/String charAt(I)C
> interpreter: java/lang/String indexOf(I)I
> interpreter: java/lang/String indexOf(II)I
> interpreter: java/lang/String length()I
> ...
>
> I'm not sure why all of this is being interpreted for a simple hello
> world program. My understanding was that the interpreter traverses the
> byte code for the given input and then handles the executed byte codes.
> It seems like a lot more is going on here.
>
> Also, I am trying to become familiar with the jit and interpreter by
> reading the DRL Developer's Guide. Are there any other resources other
> than the Developer's Guide and this mailing list?
>
>
> Thanks
> Armand
>
--
Egor Pasko, Intel Managed Runtime Division
RE: Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 :) Sorry for delay... Cheers, Sveta Konovalova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Tuesday, October 24, 2006 10:19 AM To: harmony-dev@incubator.apache.org Subject: Re: [vote] Graduate Apache Harmony podling from the Incubator +1 (no surprize here) sorry for delay :( On the 0x209 day of Apache Harmony Geir Magnusson, Jr. wrote: > We're trying something a little different. I think Roy Fielding one > said something along the lines of "when a community gets organized > enough to vote itself out of the Incubator, it's appropriate." > > So to bring the Harmony community and the Incubator community together > for this important event in Harmony's life, I'm calling for a vote on > graduating Harmony here on our own -dev list. The objective is for > all in both the Harmony community and the Incubator community that > have an opinion to vote together, in the same place, and have it > "hosted" by the Harmony podling. > > This is an unconventional way to do this, but I think that it's valid > and could provide one example to the Incubator on how it can work > going forward. > > So, without any further ado : > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition > the board for Top Level Project status > > [ ] 0 No opinion > > [ ] -1 No, don't graduate Harmony. Here's why : > > > This vote will end 72 hours from now + time of Apache mail outage. It > will therefore end on Monday, October 23, at 3:30 PM eastern, + delta > for mail outage. > > Thanks > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Egor Pasko, Intel Managed Runtime Division
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 (no surprize here) sorry for delay :( On the 0x209 day of Apache Harmony Geir Magnusson, Jr. wrote: > We're trying something a little different. I think Roy Fielding one > said something along the lines of "when a community gets organized > enough to vote itself out of the Incubator, it's appropriate." > > So to bring the Harmony community and the Incubator community together > for this important event in Harmony's life, I'm calling for a vote on > graduating Harmony here on our own -dev list. The objective is for > all in both the Harmony community and the Incubator community that > have an opinion to vote together, in the same place, and have it > "hosted" by the Harmony podling. > > This is an unconventional way to do this, but I think that it's valid > and could provide one example to the Incubator on how it can work > going forward. > > So, without any further ado : > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition > the board for Top Level Project status > > [ ] 0 No opinion > > [ ] -1 No, don't graduate Harmony. Here's why : > > > This vote will end 72 hours from now + time of Apache mail outage. It > will therefore end on Monday, October 23, at 3:30 PM eastern, + delta > for mail outage. > > Thanks > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Egor Pasko, Intel Managed Runtime Division
[classlib][General]Problem in plug-in dependencies
Hi, all: After rebuilt current Harmony classlib, I found several source jars have replaced the binary jar in the classpath of plug-in dependencies, for example, the nio-char_src.jar instead of nio-char.jar. Thus it lead to the failure of project building in eclipse. -- Leo Li China Software Development Lab, IBM
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Nathan, I tend to agree with you. I believe even with "private" modifier set IllegalAccessException should not be thrown in the test case. What really worries me is why getEnclosingClass returns null...it is a bug definitelyI think it should be resolved first... Evgueni On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: On 10/23/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: > I think we have several different items/questions to discuss: > > 1) Is it legal to generate "private" modifier to a local class? > The Java Language Specification, Third Edition part 14.3 states > > It is a compile-time error if a local class declaration contains any > one of the following access modifiers: public, protected, private, or > static. > > So it seems a compiler isn't allowed to put "private" modifier. Thoughts? This is the part I was commenting, so I put my thoughts here. This is from the language specification and only applies to Java syntax and yes, that's an error and it makes sense. But from the class file (bytecode) perspective, a local class must be defined in its own file and this class is not accessible by any other class in the package (not default or package-private scope), so I would think that it should be marked private. My reasoning would be that the language spec is saying a class modifier is illegal for a local class because within the scope of a method there is no concept or more or less accessible than the method. Thus, if we promoted this concept to an inner class, it would be conceptually the same as a private inner class because it would be off limits from other classes in the same package. I think what the language specification is say here is much like the scope identifiers of methods on an interface. If the interface is public, all methods are public, even if they aren't declared public. > > 2) getEnclosingClass and isLocalClass doesn't give correct result when > compiled with ECJ. It seems to be a seperate problem but this can > affect the algorithm which determines member accessibility. Seems this > should be resolved first. > > 3) Elena and I looked at the algorithm which determines member > accessibility and found a problem in it. To resolve the problem we > need to fix getEnclosingClass. So I propose to concentrate on this > method for now. > > Evgueni > > On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: > > By "inner class" you mean an automatic/local class in this case; a > > class declared inside a method. It would seem appropriate that a local > > class is declared private. Only the method that contains the class > > declaration can see it. > > > > Do you disagree with what ECJ is generating? > > > > -Nathan > > > > On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > > On Sunday 22 October 2006 01:08 Nathan Beyer wrote: > > > > I haven't had a chance to look at the issue (JIRAs down right now, > > > > probably part of the infrastructure move), but have you tried > > > > comparing the actual class files of the problematic class or classes. > > > > > > > > I'd suggest compiling the files using ECJ, save them off, compile with > > > > Sun/BEA/etc, save them off and then run javap from a single JDK on > > > > each of the class files and compare them for differences. > > > > > > Yes, it is quite interesting how different compilers produce different class > > > attributes, it looks like this is the main problem with the code. ECJ insists > > > on marking inner classes private. Elena was kind to send me another test > > > which she wrote while JIRA was down and it shows even a bigger difference > > > between the compilers - it produces different output on RI. In the 2nd test > > > ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun > > > creates Test1931_2$1LocalClass. This gives different output from > > > cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class. > > > > > > Nevertheless RI allows the access to the inner private class it seems. It > > > doesn't throw the exception which drlvm does. The exception source is drlvm's > > > kernel class ReflectExporter and the method in question is allowAccess which > > > calls allowClassAccess at line 113. This check is the one and the only chance > > > to return true in this case. > > > > > > I've debugged the code with recently implemented debugging support of drlvm > > > using eclipse (jdwp agent has to be build for this from HARMONY-1410, also > > > kernel classes for drlvm aren't compiled with debug support, build script has > > > to be hacked) but I just don't know all of the access checks specification > > > statements to make a decision which one is not correct. > > > > > > P.S. I used ecj 3.2 which we use for current classlib compilation. > > > > > > -- > > > Gregory Shimansky, Intel Middleware Products Division > > > > > >
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
On 10/24/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: I think we have several different items/questions to discuss: 1) Is it legal to generate "private" modifier to a local class? The Java Language Specification, Third Edition part 14.3 states It is a compile-time error if a local class declaration contains any one of the following access modifiers: public, protected, private, or static. So it seems a compiler isn't allowed to put "private" modifier. Thoughts? The spec says about class declaration but not compiled class modifiers. Sun's compiler provides the "public" modifier for a local class while ECJ sets it to "private", which seems more appropriate. 2) getEnclosingClass and isLocalClass doesn't give correct result when compiled with ECJ. It seems to be a seperate problem but this can affect the algorithm which determines member accessibility. Seems this should be resolved first. 3) Elena and I looked at the algorithm which determines member accessibility and found a problem in it. To resolve the problem we need to fix getEnclosingClass. So I propose to concentrate on this method for now. Evgueni On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: > By "inner class" you mean an automatic/local class in this case; a > class declared inside a method. It would seem appropriate that a local > class is declared private. Only the method that contains the class > declaration can see it. > > Do you disagree with what ECJ is generating? > > -Nathan > > On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > On Sunday 22 October 2006 01:08 Nathan Beyer wrote: > > > I haven't had a chance to look at the issue (JIRAs down right now, > > > probably part of the infrastructure move), but have you tried > > > comparing the actual class files of the problematic class or classes. > > > > > > I'd suggest compiling the files using ECJ, save them off, compile with > > > Sun/BEA/etc, save them off and then run javap from a single JDK on > > > each of the class files and compare them for differences. > > > > Yes, it is quite interesting how different compilers produce different class > > attributes, it looks like this is the main problem with the code. ECJ insists > > on marking inner classes private. Elena was kind to send me another test > > which she wrote while JIRA was down and it shows even a bigger difference > > between the compilers - it produces different output on RI. In the 2nd test > > ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun > > creates Test1931_2$1LocalClass. This gives different output from > > cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class. > > > > Nevertheless RI allows the access to the inner private class it seems. It > > doesn't throw the exception which drlvm does. The exception source is drlvm's > > kernel class ReflectExporter and the method in question is allowAccess which > > calls allowClassAccess at line 113. This check is the one and the only chance > > to return true in this case. > > > > I've debugged the code with recently implemented debugging support of drlvm > > using eclipse (jdwp agent has to be build for this from HARMONY-1410, also > > kernel classes for drlvm aren't compiled with debug support, build script has > > to be hacked) but I just don't know all of the access checks specification > > statements to make a decision which one is not correct. > > > > P.S. I used ecj 3.2 which we use for current classlib compilation. > > > > -- > > Gregory Shimansky, Intel Middleware Products Division > > > -- Thanks, Elena
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
On 10/23/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: I think we have several different items/questions to discuss: 1) Is it legal to generate "private" modifier to a local class? The Java Language Specification, Third Edition part 14.3 states It is a compile-time error if a local class declaration contains any one of the following access modifiers: public, protected, private, or static. So it seems a compiler isn't allowed to put "private" modifier. Thoughts? This is the part I was commenting, so I put my thoughts here. This is from the language specification and only applies to Java syntax and yes, that's an error and it makes sense. But from the class file (bytecode) perspective, a local class must be defined in its own file and this class is not accessible by any other class in the package (not default or package-private scope), so I would think that it should be marked private. My reasoning would be that the language spec is saying a class modifier is illegal for a local class because within the scope of a method there is no concept or more or less accessible than the method. Thus, if we promoted this concept to an inner class, it would be conceptually the same as a private inner class because it would be off limits from other classes in the same package. I think what the language specification is say here is much like the scope identifiers of methods on an interface. If the interface is public, all methods are public, even if they aren't declared public. 2) getEnclosingClass and isLocalClass doesn't give correct result when compiled with ECJ. It seems to be a seperate problem but this can affect the algorithm which determines member accessibility. Seems this should be resolved first. 3) Elena and I looked at the algorithm which determines member accessibility and found a problem in it. To resolve the problem we need to fix getEnclosingClass. So I propose to concentrate on this method for now. Evgueni On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: > By "inner class" you mean an automatic/local class in this case; a > class declared inside a method. It would seem appropriate that a local > class is declared private. Only the method that contains the class > declaration can see it. > > Do you disagree with what ECJ is generating? > > -Nathan > > On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > On Sunday 22 October 2006 01:08 Nathan Beyer wrote: > > > I haven't had a chance to look at the issue (JIRAs down right now, > > > probably part of the infrastructure move), but have you tried > > > comparing the actual class files of the problematic class or classes. > > > > > > I'd suggest compiling the files using ECJ, save them off, compile with > > > Sun/BEA/etc, save them off and then run javap from a single JDK on > > > each of the class files and compare them for differences. > > > > Yes, it is quite interesting how different compilers produce different class > > attributes, it looks like this is the main problem with the code. ECJ insists > > on marking inner classes private. Elena was kind to send me another test > > which she wrote while JIRA was down and it shows even a bigger difference > > between the compilers - it produces different output on RI. In the 2nd test > > ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun > > creates Test1931_2$1LocalClass. This gives different output from > > cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class. > > > > Nevertheless RI allows the access to the inner private class it seems. It > > doesn't throw the exception which drlvm does. The exception source is drlvm's > > kernel class ReflectExporter and the method in question is allowAccess which > > calls allowClassAccess at line 113. This check is the one and the only chance > > to return true in this case. > > > > I've debugged the code with recently implemented debugging support of drlvm > > using eclipse (jdwp agent has to be build for this from HARMONY-1410, also > > kernel classes for drlvm aren't compiled with debug support, build script has > > to be hacked) but I just don't know all of the access checks specification > > statements to make a decision which one is not correct. > > > > P.S. I used ecj 3.2 which we use for current classlib compilation. > > > > -- > > Gregory Shimansky, Intel Middleware Products Division > > >
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
I think we have several different items/questions to discuss: 1) Is it legal to generate "private" modifier to a local class? The Java Language Specification, Third Edition part 14.3 states It is a compile-time error if a local class declaration contains any one of the following access modifiers: public, protected, private, or static. So it seems a compiler isn't allowed to put "private" modifier. Thoughts? 2) getEnclosingClass and isLocalClass doesn't give correct result when compiled with ECJ. It seems to be a seperate problem but this can affect the algorithm which determines member accessibility. Seems this should be resolved first. 3) Elena and I looked at the algorithm which determines member accessibility and found a problem in it. To resolve the problem we need to fix getEnclosingClass. So I propose to concentrate on this method for now. Evgueni On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: By "inner class" you mean an automatic/local class in this case; a class declared inside a method. It would seem appropriate that a local class is declared private. Only the method that contains the class declaration can see it. Do you disagree with what ECJ is generating? -Nathan On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > On Sunday 22 October 2006 01:08 Nathan Beyer wrote: > > I haven't had a chance to look at the issue (JIRAs down right now, > > probably part of the infrastructure move), but have you tried > > comparing the actual class files of the problematic class or classes. > > > > I'd suggest compiling the files using ECJ, save them off, compile with > > Sun/BEA/etc, save them off and then run javap from a single JDK on > > each of the class files and compare them for differences. > > Yes, it is quite interesting how different compilers produce different class > attributes, it looks like this is the main problem with the code. ECJ insists > on marking inner classes private. Elena was kind to send me another test > which she wrote while JIRA was down and it shows even a bigger difference > between the compilers - it produces different output on RI. In the 2nd test > ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun > creates Test1931_2$1LocalClass. This gives different output from > cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class. > > Nevertheless RI allows the access to the inner private class it seems. It > doesn't throw the exception which drlvm does. The exception source is drlvm's > kernel class ReflectExporter and the method in question is allowAccess which > calls allowClassAccess at line 113. This check is the one and the only chance > to return true in this case. > > I've debugged the code with recently implemented debugging support of drlvm > using eclipse (jdwp agent has to be build for this from HARMONY-1410, also > kernel classes for drlvm aren't compiled with debug support, build script has > to be hacked) but I just don't know all of the access checks specification > statements to make a decision which one is not correct. > > P.S. I used ecj 3.2 which we use for current classlib compilation. > > -- > Gregory Shimansky, Intel Middleware Products Division >
Re: [classlib][test] Configuration dependent test of InetAddress.getHostName
On 10/20/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
Denis,
Can we consider a patch from
http://issues.apache.org/jira/browse/HARMONY-73 as a fourth option?
Simply speaking, the patch adds a conditional operator which forces API
to returning "localhost" in this case.
No. I think Harmony does the right thing. We can't force harmony to return
"localhost", which should depend on host file.
The evil is the test. I think we'd better revise the test.
Paulex,
This is your patch. What do you think?
With best regards,
Alexei Fedotov,
Intel Java & XML Engineering
>-Original Message-
>From: Denis Kishenko [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 19, 2006 3:44 PM
>To: harmony-dev@incubator.apache.org
>Subject: [classlib][test] Configuration dependent test of
>InetAddress.getHostName
>
>I have researched issue H-1664 and found one more difference with RI.
>I run simple test on Windows Server 2003 SP1
>
>=== Test =
>import java.net.InetAddress;
>import java.net.UnknownHostException;
>
>public class Test {
>public static void main(String[] args) throws UnknownHostException
{
>System.out.println("by name (127.0.0.1) -> " +
>InetAddress.getByName("127.0.0.1").getHostName());
>System.out.println("by name (localhost) -> " +
>InetAddress.getByName("localhost").getHostName());
>System.out.println("by address -> " +
>InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
>System.out.println("localhost -> " +
InetAddress.getLocalHost());
>}
>
>}
>
>Windows Server 2003 SP1
>=== RI ==
>by name (127.0.0.1) -> 127.0.0.1
>by name (localhost) -> localhost
>by address -> 127.0.0.1
>localhost -> nstdrlew21/10.125.122.60
>
>= Harmony ==
>by name (127.0.0.1) -> nstdrlew21.ins.intel.com
>by name (localhost) -> localhost
>by address -> nstdrlew21.ins.intel.com
>localhost -> nstdrlew21/10.125.122.60
>
>WinXP
>= Both ===
>by name (127.0.0.1) -> localhost
>by name (localhost) -> localhost
>by address -> localhost
>localhost -> pbwdmkishen/10.125.132.226
>
>
>Actually Harmony use native call of getnameinfo() to get host name
>(which is reasonable IMHO). MSDN says "The getnameinfo function
>provides name resolution from an address to the host name".
>
>InetAddressTest.test_getHostName (see H-1664) failed on WinServer
>because InetAddress.getByName("127.0.0.1").getHostName() returned
>"nstdrlew21.ins.intel.com" while "localhost" expected. So this test
>looks like configuration dependent.
>
>I see three possible options
>1. Stay test as is. Just keep in mind that on specific configurations
>this one fails.
>2. Rewrite test to be configuration dependent. Test has to do the same
>native call.
>3. Exclude localhost checking from test_getHostName.
>
>What do you think about this situation?
>
>--
>Denis M. Kishenko
>Enterprise Solutions Software Division
>
>-
>Terms of use : http://incubator.apache.org/harmony/mailing.html
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best regards,
Andrew Zhang
Re: Harmony passes 94% on derby tests.
Leo Li 写道: 467 Tests Run 94% Pass (443 tests passed) 6% Fail (24 tests failed) 5 Suites skipped The main progress focuses here: 1. Harmony classlib fails to load class when user-defined security policy exists. It is due to the sequence of library loading of VM, which has been resolved now. 2. A new workround for derby tests which allow useprocess to run test or else several testcases might fail due to derby lack these tests when useprocess = false. 3. Derby source code uses the version and the name of java vm to decide what to do, while current IBM VM has the version of "1.4.2" and the name of "j9", which has different output on the screen from that of standard RI 1.5. At the same time Derby test compares the output of the iteractive test scripts to that of expected. I have made some slight modification in its source code, but I have not throughly change this odd behavior, ...,too much:( Besides, some testcase fails even on RI. I exclude a "derbynetclientmats" test suit since it will hang both RI and Harmony. Currently all the failure is irrelevant to Harmony. Hope I can find something in the left. I have updated the wiki of derby on Hamony: http://wiki.apache.org/harmony/Apache_Derby. Hi Leo: It's really great! After reading through your post and several other disscussions on the mailing list, I have a feeling that most of the failure are caused by the of the test suite itself. Correct me if I am wrong. Can we improve the test suites themself to lift up the test rate on harmony? Best regards -- Spark Shen China Software Development Lab, IBM
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 certainly. Pavel Pervov, Enterprise Solutions Software Division. On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Harmony passes 94% on derby tests.
congratulations! On 10/23/06, Leo Li <[EMAIL PROTECTED]> wrote: 467 Tests Run 94% Pass (443 tests passed) 6% Fail (24 tests failed) 5 Suites skipped The main progress focuses here: 1. Harmony classlib fails to load class when user-defined security policy exists. It is due to the sequence of library loading of VM, which has been resolved now. 2. A new workround for derby tests which allow useprocess to run test or else several testcases might fail due to derby lack these tests when useprocess = false. 3. Derby source code uses the version and the name of java vm to decide what to do, while current IBM VM has the version of "1.4.2" and the name of "j9", which has different output on the screen from that of standard RI 1.5. At the same time Derby test compares the output of the iteractive test scripts to that of expected. I have made some slight modification in its source code, but I have not throughly change this odd behavior, ...,too much:( Besides, some testcase fails even on RI. I exclude a "derbynetclientmats" test suit since it will hang both RI and Harmony. Currently all the failure is irrelevant to Harmony. Hope I can find something in the left. I have updated the wiki of derby on Hamony: http://wiki.apache.org/harmony/Apache_Derby. -- Leo Li China Software Development Lab, IBM -- Tony Wu China Software Development Lab, IBM
Re: [build] Problem with fetch-depends part of build script
JIRA was probably still down as part of the ASF infrastructure moves. Is this still an issue? On 10/23/06, Sian January <[EMAIL PROTECTED]> wrote: Hello, This morning I have been trying to build Harmony and I'm having a problem with the fetch-depends part of the build script. I am getting the following output: Buildfile: *C:\eclipse32harmony\eclipse\workspace\Harmony\build.xml fetch-depends*: * -download*: [*echo*] Checking depends/jars/yoko-m1/yoko.jar * -really-download*: [*echo*] Fetching depends/jars/yoko-m1/yoko.jar [*get*] Getting: http://people.apache.org/maven-snapshot-repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M1-SNAPSHOT/yoko-spec-corba-1.0-incubating-M1-20060925.152805-4.jar [*get*] To: C:\eclipse32harmony\eclipse\workspace\Harmony\depends\jars\yoko-m1\yoko.jar [*get*] . [*get*] last modified = Thu Jan 01 01:00:00 GMT 1970 - using current time instead * -remove-file-if-bad*: BUILD FAILED * C:\eclipse32harmony\eclipse\workspace\Harmony\build.xml:275: The following error occurred while executing this line: C:\eclipse32harmony\eclipse\workspace\Harmony\make\depends.xml:158: The following error occurred while executing this line: C:\eclipse32harmony\eclipse\workspace\Harmony\make\depends.xml:248: ... * File depends/jars/yoko-m1/yoko.jar has incorrect md5 checksum. Expected: 87e62e170dd07cc9c31b9045395f3d10 found: 105a567dc9b27cbcaab4fe058021786e Total time: 2 minutes 8 seconds I have tried to run it a few times and also tried deleting the existing jars. Can anyone help with this problem? Thanks, Sian -- Sian January IBM Java Technology Centre, UK
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
By "inner class" you mean an automatic/local class in this case; a class declared inside a method. It would seem appropriate that a local class is declared private. Only the method that contains the class declaration can see it. Do you disagree with what ECJ is generating? -Nathan On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: On Sunday 22 October 2006 01:08 Nathan Beyer wrote: > I haven't had a chance to look at the issue (JIRAs down right now, > probably part of the infrastructure move), but have you tried > comparing the actual class files of the problematic class or classes. > > I'd suggest compiling the files using ECJ, save them off, compile with > Sun/BEA/etc, save them off and then run javap from a single JDK on > each of the class files and compare them for differences. Yes, it is quite interesting how different compilers produce different class attributes, it looks like this is the main problem with the code. ECJ insists on marking inner classes private. Elena was kind to send me another test which she wrote while JIRA was down and it shows even a bigger difference between the compilers - it produces different output on RI. In the 2nd test ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun creates Test1931_2$1LocalClass. This gives different output from cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class. Nevertheless RI allows the access to the inner private class it seems. It doesn't throw the exception which drlvm does. The exception source is drlvm's kernel class ReflectExporter and the method in question is allowAccess which calls allowClassAccess at line 113. This check is the one and the only chance to return true in this case. I've debugged the code with recently implemented debugging support of drlvm using eclipse (jdwp agent has to be build for this from HARMONY-1410, also kernel classes for drlvm aren't compiled with debug support, build script has to be hacked) but I just don't know all of the access checks specification statements to make a decision which one is not correct. P.S. I used ecj 3.2 which we use for current classlib compilation. -- Gregory Shimansky, Intel Middleware Products Division
Re: [vote] Graduate Apache Harmony podling from the Incubator
Hi Folks, Sorry for the delay. [ +1] Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status -- dims -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: [vote] Graduate Apache Harmony podling from the Incubator
Yeah, harmony is sorta fun. has more than 640 subscribers on the dev list! that's a lot for a podling. That is double of that what we have at myfaces! so let's move forward here! -M On 10/20/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote: +1 As far as I understand the main goal of incubation is creation of healthy community. It means that all these non-binding +1 votes do bind us to this project. :-) With best regards, Alexei Fedotov, Intel Java & XML Engineering >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >Matthias Wessendorf >Sent: Saturday, October 21, 2006 1:47 AM >To: harmony-dev@incubator.apache.org >Subject: Re: [vote] Graduate Apache Harmony podling from the Incubator > >Since I am not a committer or ppmc of this podling, my vote is non-binding. > >+1 > >hope to get the Trinidad Podling build done by Harmony soon! >;) > >-Matthias > >On 10/20/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: >> +1 from me! >> >> On 10/21/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: >> > >> > On 20/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition >the >> > > board for Top Level Project status >> > >> > +1 from me too. >> > >> > Alex. >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> -- >> Mikhail Fursov >> >> > > >-- >Matthias Wessendorf >http://tinyurl.com/fmywh > >further stuff: >blog: http://jroller.com/page/mwessendorf >mail: mwessendorf-at-gmail-dot-com > >- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
On Sunday 22 October 2006 01:08 Nathan Beyer wrote: > I haven't had a chance to look at the issue (JIRAs down right now, > probably part of the infrastructure move), but have you tried > comparing the actual class files of the problematic class or classes. > > I'd suggest compiling the files using ECJ, save them off, compile with > Sun/BEA/etc, save them off and then run javap from a single JDK on > each of the class files and compare them for differences. Yes, it is quite interesting how different compilers produce different class attributes, it looks like this is the main problem with the code. ECJ insists on marking inner classes private. Elena was kind to send me another test which she wrote while JIRA was down and it shows even a bigger difference between the compilers - it produces different output on RI. In the 2nd test ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun creates Test1931_2$1LocalClass. This gives different output from cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class. Nevertheless RI allows the access to the inner private class it seems. It doesn't throw the exception which drlvm does. The exception source is drlvm's kernel class ReflectExporter and the method in question is allowAccess which calls allowClassAccess at line 113. This check is the one and the only chance to return true in this case. I've debugged the code with recently implemented debugging support of drlvm using eclipse (jdwp agent has to be build for this from HARMONY-1410, also kernel classes for drlvm aren't compiled with debug support, build script has to be hacked) but I just don't know all of the access checks specification statements to make a decision which one is not correct. P.S. I used ecj 3.2 which we use for current classlib compilation. -- Gregory Shimansky, Intel Middleware Products Division
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 from me ! thanks, Pavel On 10/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][test] Configuration dependent test of InetAddress.getHostName
Hello, All,
Paulex wrote,
>> the test needs to be rewritten or excluded
+1, and the option to exclude the test is pretty understandable.
I wonder about the first option. Is there any way to check that symbolic
name corresponds to the local computer? I can imagine the following
condition to check this.
InetAddress.getByName(InetAddress.getByName("127.0.0.1").getHostName()).
isLoopbackAddress()
Thoughts?
With best regards,
Alexei Fedotov,
Intel Java & XML Engineering
>-Original Message-
>From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
>Sent: Monday, October 23, 2006 6:47 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][test] Configuration dependent test of
>InetAddress.getHostName
>
>> I think Harmony does the right thing as spec requires, the difference
is
>> caused by underlying system call, so it should be acceptable, i.e.,
the
>> test needs to be rewritten or excluded.
>
>+1 from me
>
>Thanks,
>
>2006/10/20, Paulex Yang <[EMAIL PROTECTED]>:
>> Denis Kishenko wrote:
>> > I have researched issue H-1664 and found one more difference with
RI.
>> > I run simple test on Windows Server 2003 SP1
>> >
>> > === Test =
>> > import java.net.InetAddress;
>> > import java.net.UnknownHostException;
>> >
>> > public class Test {
>> >public static void main(String[] args) throws
UnknownHostException {
>> >System.out.println("by name (127.0.0.1) -> " +
>> > InetAddress.getByName("127.0.0.1").getHostName());
>> >System.out.println("by name (localhost) -> " +
>> > InetAddress.getByName("localhost").getHostName());
>> >System.out.println("by address -> " +
>> > InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
>> >System.out.println("localhost -> " +
>InetAddress.getLocalHost());
>> >}
>> >
>> > }
>> >
>> > Windows Server 2003 SP1
>> > === RI ==
>> >by name (127.0.0.1) -> 127.0.0.1
>> >by name (localhost) -> localhost
>> >by address -> 127.0.0.1
>> >localhost -> nstdrlew21/10.125.122.60
>> >
>> > = Harmony ==
>> >by name (127.0.0.1) -> nstdrlew21.ins.intel.com
>> >by name (localhost) -> localhost
>> >by address -> nstdrlew21.ins.intel.com
>> >localhost -> nstdrlew21/10.125.122.60
>> >
>> > WinXP
>> > = Both ===
>> > by name (127.0.0.1) -> localhost
>> > by name (localhost) -> localhost
>> > by address -> localhost
>> > localhost -> pbwdmkishen/10.125.132.226
>> >
>> >
>> > Actually Harmony use native call of getnameinfo() to get host name
>> > (which is reasonable IMHO). MSDN says "The getnameinfo function
>> > provides name resolution from an address to the host name".
>> >
>> > InetAddressTest.test_getHostName (see H-1664) failed on WinServer
>> > because InetAddress.getByName("127.0.0.1").getHostName() returned
>> > "nstdrlew21.ins.intel.com" while "localhost" expected. So this test
>> > looks like configuration dependent.
>> >
>> > I see three possible options
>> > 1. Stay test as is. Just keep in mind that on specific
configurations
>> > this one fails.
>> > 2. Rewrite test to be configuration dependent. Test has to do the
same
>> > native call.
>> > 3. Exclude localhost checking from test_getHostName.
>> I think Harmony does the right thing as spec requires, the difference
is
>> caused by underlying system call, so it should be acceptable, i.e.,
the
>> test needs to be rewritten or excluded. But this issue worth a
non-bug
>> difference together with getHostName()'s different behavior when
>> SecurityManager presents[1](thanks Alexei Fedotov helped to find this
>> link and commented to HARMONY-1664:))
>>
>> Harmony-73 is another issue, which is actually caused by HARMONY-84
and
>> irrelevant with getHostName() method.
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-
>dev/200602.mbox/[EMAIL PROTECTED]
>> >
>> > What do you think about this situation?
>
>--
>Alexei Zakharov,
>Intel Enterprise Solutions Software Division
Re: [drlvm] Using JNI methods in VM's components.
On Monday 23 October 2006 14:15 Pavel Pervov wrote:
> Mikhail,
>
> can relative path be specified in -Dvm.gc_dll/-Dvm.em_dll? If so, the path
> should be extended to represent full path.
So it should be something like
class GCv5Magics {
static {
String gcPath = System.getProperty("vm.gc_dll");
if (gcPath != null) {
try {
gcPath = (new File(gcPath)).getCanonicalName();
} catch (IOException e) {
System.err.println("Failed to find library specified in
\"vm.gc_dll\" property: " + e);
System.loadLibrary("gc");
return;
}
System.load(gcPath);
}
else {
System.loadLibrary("gc");
}
}
}
> On 10/21/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
> > On 10/21/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > > This is the reason I've corrected the code. Doesn't it mean that is you
> > > specified something in -Dvm.em_dll on command line that
> >
> > System.getProperty
> >
> > > would return non null value, and then you shall use System.load instead
> >
> > of
> >
> > > System.loadLibrary? That is if you change gc to em in the code above.
> >
> > Gregory, I have completely forgotten about System.load() and
> > System.loadLibrary() differences. So the problem is solved and I have
> > even tested the code :)
> >
> >
> >
> > --
> > Mikhail Fursov
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] A list of drlvm enhancements and limitations
On Monday 23 October 2006 20:21 Weldon Washburn wrote: > All, > Just a few minutes ago I sent a mail titled, "[DRLVM][MMTk]" current status > and plan". It is way too long and detailed to include in this list of > drlvm enhancements. Below is a summary that hopefully is at the > appropriate level of detail. Please refer to the above email for more > information. > > Summary of MMTk projects > 1) > Move the exiting "uswer-level" MMTk port to GCV5 > 2) > Get MMTk SemiSpace, GenMS and CopyMS collector running again. They were > broken during migration to latest MMTk source and latest drlvm svn HEAD. > 3) > Alter DRLVM classloader to force all MMTk classes to be loaded and all > methods to be JITed before any java code is executed. Integrate MMTk into > an early stage of DRLVM boot. > 4) > Fix up MMTk/VM porting layer which is located at: > drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk > 5) > Debug and verify JIT support for MMTk's Uninterruptible class. Run simple > multithread app and debug. > > On 10/17/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > Hi Gregory, > >It is a good idea to put up a live list, thanks. Here are some > > suggestions on the contents for development items in the VM/JIT. A few > > may be almost done. We can fine tune...and add other work items as well > > > > > > - MMTk integration: > > Support for magic classes in Jitrino > > VM/JIT support for MMTk collectors including RSE and thread suspension > > > > ( Weldon, could you please add details?) Weldon, can you make a subpage to Rana's list and link it to the MMTK integration item? -- Gregory Shimansky, Intel Middleware Products Division
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
On Monday 23 October 2006 22:05 Mikhail Fursov wrote: > Pavel, I see no attachment.. ? I think Geir has commented on this once. Apache mail list filters some types of attachments away (IIRC to keep all intellectual property clean from code taken from unknown code sources). To make some files public to everyone create a JIRA and attach files to it. -- Gregory Shimansky, Intel Middleware Products Division
Re: [general] Incubator graduation update
Lets stuff the whole thing in there... robert burrell donkin wrote: On 10/23/06, Matt Benson <[EMAIL PROTECTED]> wrote: --- "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: [SNIP] > First, there are minor 'nits' here and there related > to license and > license headers. For example, we're missing the > antlr license in our > NOTICE file. wrt this particular "nit", antlr 2.x.x versions are public domain... text: --- ANTLR 2 License We reserve no legal rights to the ANTLR--it is fully in the public domain. An individual or company may do whatever they wish with source code distributed with ANTLR or the code generated by ANTLR, including the incorporation of ANTLR, or its output, into commerical software. We encourage users to develop software with ANTLR. However, we do ask that credit is given to us for developing ANTLR. By "credit", we mean that if you use ANTLR or incorporate any source code into one of your programs (commercial product, research project, or otherwise) that you acknowledge this fact somewhere in the documentation, research report, etc... If you like ANTLR and have developed a nice tool with the output, please mention that you developed it using ANTLR. In addition, we ask that the headers remain intact in our source code. As long as these guidelines are kept, we expect to continue enhancing this system and expect to make other tools available as they are completed. --- so any form of acknowledgement is probably good enough to satisfy Terence. the public domain has become difficult in recent times. in some jurisdictions (in europe), i believe that an explicit license is required. (yes, i know it's daft.) copyright may also now be primarily criminal matter between the state and the copier. the opinions of the author matter little. so, it's best to include the statement. and a note to the notice file to acknowledge Terence :-) - robert
[drlvm] A list of drlvm enhancements and limitations
-- Forwarded message -- From: Weldon Washburn <[EMAIL PROTECTED]> Date: Oct 23, 2006 9:21 AM Subject: Re: [drlvm] A list of drlvm enhancements and limitations To: harmony-dev@incubator.apache.org All, Just a few minutes ago I sent a mail titled, "[DRLVM][MMTk]" current status and plan". It is way too long and detailed to include in this list of drlvm enhancements. Below is a summary that hopefully is at the appropriate level of detail. Please refer to the above email for more information. Summary of MMTk projects 1) Move the exiting "uswer-level" MMTk port to GCV5 2) Get MMTk SemiSpace, GenMS and CopyMS collector running again. They were broken during migration to latest MMTk source and latest drlvm svn HEAD. 3) Alter DRLVM classloader to force all MMTk classes to be loaded and all methods to be JITed before any java code is executed. Integrate MMTk into an early stage of DRLVM boot. 4) Fix up MMTk/VM porting layer which is located at: drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk 5) Debug and verify JIT support for MMTk's Uninterruptible class. Run simple multithread app and debug. On 10/17/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: Hi Gregory, It is a good idea to put up a live list, thanks. Here are some suggestions on the contents for development items in the VM/JIT. A few may be almost done. We can fine tune...and add other work items as well - MMTk integration: Support for magic classes in Jitrino VM/JIT support for MMTk collectors including RSE and thread suspension ( Weldon, could you please add details?) Thanks > On 10/16/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > Once it's more or less ready let's point to that page from TODO on our > > website > > > > Thanks, > > Mikhail > > > > 2006/10/17, Gregory Shimansky < [EMAIL PROTECTED]>: > > > Hello > > > > > > You know that drlvm was donated by Intel and there was some period of > > time > > > while drlvm was developed internally. We had an internal bugzilla > > server to > > > track the issues. In an effort to move all development to the open > > this > > > internal bugzilla will be closed. > > > > > > The database is quite big and contains a lot of valuable information > > including > > > still open bugs. There are many of them which are not exactly bug > > reports, > > > but requests for enhancements or limitation problems. These small > > issues > > > didn't make it to README because they are mostly minor and low > > priority, but > > > it is better to use information which we have already than rediscover > > these > > > problems again. > > > > > > So not to create a lot of garbage in JIRA like problem requests > > without > > > patches I think it is better to create something like a TODO list for > > drlvm. > > > Not exactly bugs, but more like known limitations list. > > > > > > To give you an example, vm/vmcore/src/init/properties.cpp contains a > > #define > > > MAX_PROP_LINE 5120 which is a maximum property length specified in > > > vm.properties file. I am not even sure if this file still used, > > probably not, > > > but a buffer length limitation is still a bad thing. > > > > > > I think a good place for such list would be on wiki. I am going to > > create a > > > page for it so that everyone who has open bugs inside of Intel could > > add a > > > line or two describing a problem recorded in bugzilla. I have 3 like > > these > > > filed myself including the one I gave as an example. > > > > > > I don't know the number of such bugs overall, maybe it is not so big. > > But > > > before creating JIRAs for them I think it is better to collect a list > > on > > > wiki. What do you think? > > > > > > -- > > > Gregory Shimansky, Intel Middleware Products Division > > > > > > -- Weldon Washburn Intel Middleware Products Division -- Weldon Washburn Intel Middleware Products Division
[DRLVM][MMTk] current status and plan
-- Forwarded message -- From: Weldon Washburn <[EMAIL PROTECTED]> Date: Oct 23, 2006 9:07 AM Subject: [DRLVM][MMTk] current status and plan To: harmony-dev@incubator.apache.org Current status - Robin Garner's mmtk_20061016.zip snapshot of MMTk source now runs the simple "user-level" MarkSweep.java test on DLRVM svn HEAD of 10/20/2006. The mods to MMTk porting layer to support the above have been committed to DRLVM HEAD. The next steps for the MMTk/DRLVM port are as follows. Comments, suggestions are welcome. It would be much appreciated if Steve Blackburn and Robin Garner would reply to the questions below directed to the "MMTk guys". The following plan is roughly in the order this work should be done. - Currentlly MMTk/DRLVM runs as a "user-level" app. That is, MMTk port allocates a 450MB array from DRLVM's underlying GC. Currently only GCV4.0 supports 450MB arrays. A vmmagic "Address" object is created that points to the base of the 450MB array. MMTk is "booted" with the "Address" of the 450MB object. A simple MMTK exerciser was written in Java/vmmagic. It calls MMTk alloc() repeatedly. When MMTk runs out of memory, it will GC its "user-level" heap (the 450MB array). The underlying GCV4 is oblivious to what MMTK is doing with this 450MB array. - Project 1 - Move the existing MMTk port to GCV5. We need to remove the dependency on GCV4. - MMTk SemiSpace, GenMS and CopyMS collectors actually worked before upgrading to latest the MMTk sources and current DRLVM svn HEAD. - Project 2 - Get SemiSpace, GenMS and CopyMS collectors working again. Basically this means running TestSemiSpace.java, TestGenMS.java and TestCopyMS.java exerciser programs and debugging the problems. Known issues that need fixing: - Java write barrier in Jitrino.JET needs to be debugged - MMTk needs the two LSBs of one of the object header byte. This was somehow broken during the commit of BBC.patch. It needs to be fixed. There is email on this topic in harmony-dev. - To reduce confusion, all of MMTk java source code needs to be jitted before any MMTk methods are called. - Project 3 - Modify DLRVM classloader to force all MMTk classes to be loaded and all methods JITed before any classlib java code is executed. - The next step is to integrate MMTk in the early DRLVM boot process. The goal is to make sure all code the JIT generates will allocate out of the MMTk heap. This is a "chicken and egg" kind of problem since no JITed code can execute until DRLVM has a GC that is ready to support object allocation. Most likely we will use the MMTk notion of "ImmortalSpace" for early object allocation. Objects in ImmortalSpace are never collected, never moved. At this stage of MMTk/DRLVM porting, the cost of dead uncollected objects wasting ImmortalSpace memory is not a concern. - The existing MMTk/DRLVM porting layer is in rough shape and is incomplete. Now would be a good time to take another pass at refining the porting layer. Below are notes on fixing the porting layer which is located at: drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk - Project 4 - Assert class - This class currently causes a Null Pointer Exception to force a stack trace in each and every method. Unfortunately this means MMTk always crashes even in situations where execution is supposed to continue. Some of the APIs supposed to print the stack trace then continue execution. This needs to be fixed. - Barriers class - performWriteInBarrier() – MMTk expects to perform both the write of an object slot as well as the write barrier. The existing contract between Jitrino, VM and the GC expects that the JIT will write on the object slot then separately call the write barrier api (I think). In any case, if the JIT is still writing on the object slot, it needs to be changed to let the MMTk inlined support function to do it. - performWriteInBarrierAtomic() – this needs to be implemented (its not really needed until much later when multithread support is turned on.) - setArrayNoBarrier() – need to write some simple vmmagic code that will set an element of an array of objects without triggering a write barrier. This support is required by MMTk internal functions to prevent endless write barrier recursion. - Collection Class - triggerCollection() method needs to be connected to the Java API that forces a GC (this is low priority) - prepareMutator() method probably needs to be integrated with back-branch polling mechanism. Also need to confirm the requirement that a thread suspend request does indeed force the target
Re: [general] Incubator graduation update
--- robert burrell donkin <[EMAIL PROTECTED]> wrote: > On 10/23/06, Matt Benson <[EMAIL PROTECTED]> > wrote: > > --- "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > [SNIP] > > wrt this particular "nit", antlr 2.x.x versions > are > > public domain...> > the public domain has become difficult in recent > times. in some > jurisdictions (in europe), i believe that an > explicit license is > required. (yes, i know it's daft.) copyright may > also now be primarily > criminal matter between the state and the copier. > the opinions of the > author matter little. so, it's best to include the > statement. > > and a note to the notice file to acknowledge Terence > :-) FWIW, when ANTLR3 is fully baked, these issues will be easier as it's under a sane and relatively easy-to-interpret BSD license as compared to "custom OSS or PD license." :) -Matt > > - robert > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [general] Incubator graduation update
On 10/23/06, Matt Benson <[EMAIL PROTECTED]> wrote: --- "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: [SNIP] > First, there are minor 'nits' here and there related > to license and > license headers. For example, we're missing the > antlr license in our > NOTICE file. wrt this particular "nit", antlr 2.x.x versions are public domain... text: --- ANTLR 2 License We reserve no legal rights to the ANTLR--it is fully in the public domain. An individual or company may do whatever they wish with source code distributed with ANTLR or the code generated by ANTLR, including the incorporation of ANTLR, or its output, into commerical software. We encourage users to develop software with ANTLR. However, we do ask that credit is given to us for developing ANTLR. By "credit", we mean that if you use ANTLR or incorporate any source code into one of your programs (commercial product, research project, or otherwise) that you acknowledge this fact somewhere in the documentation, research report, etc... If you like ANTLR and have developed a nice tool with the output, please mention that you developed it using ANTLR. In addition, we ask that the headers remain intact in our source code. As long as these guidelines are kept, we expect to continue enhancing this system and expect to make other tools available as they are completed. --- so any form of acknowledgement is probably good enough to satisfy Terence. the public domain has become difficult in recent times. in some jurisdictions (in europe), i believe that an explicit license is required. (yes, i know it's daft.) copyright may also now be primarily criminal matter between the state and the copier. the opinions of the author matter little. so, it's best to include the statement. and a note to the notice file to acknowledge Terence :-) - robert
Re: svn commit: r466154 - in /incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent: ./ locks/
that's not a bad idea... Nathan Beyer wrote: This can be controlled a bit more. An svn:externals link can point to a specific revision, not just a SVN URL. This way the working copy download has to be changed at the point of link. -Nathan On 10/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Great - I wanted to make sure. I was asking based on a cursory glance. geir Nathan Beyer wrote: > They are in 'standard' and do use 'links' (svn:externals). Check out > the full path of the original commit message. Using svn:externals just > makes it seem like it's in 'extended', but that's just in your working > copy. > > -Nathan > > On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> Thanks for bringing this up. I did a classlib update this morning, and >> saw these files change, and I was confused. >> >> Why do we have the files here anyway? I thought we were going to keep >> in /standard and use links? >> >> geir >> >> Tim Ellison wrote: >> > Mark, >> > >> > I suggest that this is rolled back since it is modifying the >> concurrency >> > code in our 'standard' SVN area that we aim to keep in close sync with >> > Doug's repository. >> > >> > Perhaps we can offer the patch to that community, and/or set up local >> > compiler options to hide the warnings in this module. >> > >> > Regards, >> > Tim >> > >> > [EMAIL PROTECTED] wrote: >> >> Author: hindessm >> >> Date: Fri Oct 20 08:47:50 2006 >> >> New Revision: 466154 >> >> >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=466154 >> >> Log: >> >> Applied two patches from "[#HARMONY-1926] [build] A lot of "never >> used" >> >> and "never read" warning messages". >> >> >> >> Modified: >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ArrayBlockingQueue.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ConcurrentHashMap.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/CountDownLatch.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/DelayQueue.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Delayed.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ExecutorService.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Executors.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/FutureTask.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ScheduledExecutorService.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Semaphore.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/SynchronousQueue.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/AbstractQueuedSynchronizer.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/LockSupport.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/ReentrantLock.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/ReentrantReadWriteLock.java >> >> >> >> > >> > >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >
Re: [general] Incubator graduation update
--- "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: [SNIP] > First, there are minor 'nits' here and there related > to license and > license headers. For example, we're missing the > antlr license in our > NOTICE file. wrt this particular "nit", antlr 2.x.x versions are public domain... text: --- ANTLR 2 License We reserve no legal rights to the ANTLR--it is fully in the public domain. An individual or company may do whatever they wish with source code distributed with ANTLR or the code generated by ANTLR, including the incorporation of ANTLR, or its output, into commerical software. We encourage users to develop software with ANTLR. However, we do ask that credit is given to us for developing ANTLR. By "credit", we mean that if you use ANTLR or incorporate any source code into one of your programs (commercial product, research project, or otherwise) that you acknowledge this fact somewhere in the documentation, research report, etc... If you like ANTLR and have developed a nice tool with the output, please mention that you developed it using ANTLR. In addition, we ask that the headers remain intact in our source code. As long as these guidelines are kept, we expect to continue enhancing this system and expect to make other tools available as they are completed. --- so any form of acknowledgement is probably good enough to satisfy Terence. -Matt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [drlvm] Using JNI methods in VM's components.
Mikhail, What i've meant is that we should account for all interchangeable components which can/want/should provide fast-path helpers. Pavel. On 10/21/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: Pavel, I'm sorry I do not understand what the replacement do you mean? I said that only about a part of a component could be written in Java (e.g . EM, helpers), but not the whole component... On 10/20/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > What about TM replacement (although it is almost impossible at the > moment)? > > -- Mikhail Fursov -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [vote] Graduate Apache Harmony podling from the Incubator
Geir Magnusson Jr. wrote: > We're trying something a little different. I think Roy Fielding one > said something along the lines of "when a community gets organized > enough to vote itself out of the Incubator, it's appropriate." > > So to bring the Harmony community and the Incubator community together > for this important event in Harmony's life, I'm calling for a vote on > graduating Harmony here on our own -dev list. The objective is for all > in both the Harmony community and the Incubator community that have an > opinion to vote together, in the same place, and have it "hosted" by the > Harmony podling. > > This is an unconventional way to do this, but I think that it's valid > and could provide one example to the Incubator on how it can work going > forward. > > So, without any further ado : > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition the > board for Top Level Project status > > [ ] 0 No opinion > > [ ] -1 No, don't graduate Harmony. Here's why : +1, with my mentor hat on, there is nothing that I can say or do that will make any difference in the evolution of this project at this point in time, which means that, from an incubation point of view, Harmony is ready to move on. -- Stefano.
Re: [drlvm] Calling native methods from Java code: implementation details
Pavel, I've found only one problem in your design. Why do we need 1) if every component "must have" 2) E.g. why not to implement get_address(int) method in C language too? AFAIU Pavel Afremov's design has no C-interface methods at all. -- Mikhail Fursov
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Pavel, I see no attachment.. ? On 10/23/06, Pavel Afremov <[EMAIL PROTECTED]> wrote: Hi I've developed two "impossible" tests, which shows "fake" circularity errors. One test is more simple and use SecurityManager. The other is a bit more complex and uses custom ClassLoader. You can find them in attachment. Thanks. Pavel Afremov On 10/17/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > The scenario I described earlier is impossible. Resolution of any class > referenced in some other class is performed by class loader, which > loaded > that other class. So, no chance to load "A" and referencing class loader > (UCL) with this UCL. > > Sorry for confusion. > > Regards, >Pavel. > > P.S. Still there are concerns why lazy resolution should be supported by > > JITs. But it is absolutely another story. > > On 10/17/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > > > IMO we shall be between BEA and SUN: to work if both RI work, to fail > if > > both RI fail and discuss each test in details if only one RI passes. > > > > On 10/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > > > > > On Friday 13 October 2006 08:04 Alexey Varlamov wrote: > > > > I'm curious, if we enable "controlled" recursion in classloading - > > > > will it resolve this kind of issues completely? I'm pretty sure it > > > > would resolve at least some scenarios - like the one Pavel > described > > > > for gc.Finalizers or a case of classloading initiated within > > > > SecurityManager.checkPermission() which we also faced not once. > > > > "Controlled" recursion here means counting depth of recursion and > > > > allowing at least 1 recursive iteration. I've seen some tricks in > > > > URLClassLoader which assume such ability, but they do not work > with > > > > DRLVM. > > > > > > I think it is different. URLClassLoader is system class which is > loaded > > by > > > bootstrap, so no recursion happens for classes which it itself > requires > > to > > > be > > > loaded when it is being compiled. > > > > > > > For the pure user code scenario Pavel suggested above, there may > be > > > > some nuances leading to truly endless recursion, but still we need > to > > > > look at particular test first. > > > > > > It is not endless but it is definitely more than 1 level deep. If > user > > > sets up > > > his own class loaders, compiling them may trigger loading some of > the > > user > > > classes which are in turn loaded by class loaders set up by user. > Shall > > we > > > then throw "NoClassDefFoundError: Class loading recursion limit > reached. > > > Please rewrite your code"? :) > > > > > > -- > > > Gregory Shimansky, Intel Middleware Products Division > > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Mikhail Fursov > > > > > > -- Mikhail Fursov
Re: [drlvm][jit] Seems like too many classes loaded
Welcome Armand! My comments are inlined. On 10/23/06, Armand Navabi <[EMAIL PROTECTED]> wrote: I am trying to become more familiar with the jit code. I ran the following to see what all was compiled when running Hello World. "java -Xtrace:compile Hello". I was very surprised to see the number of methods that seem to be loaded. I think there are about 1079 methods that get compiled for Hello World. Yes you are right. To run Hello World application ~ 1000 methods are compiled. These methods are from threads, IO, classloading, security, utilities, VM infrastructure classes. 1000 methods is not a big number: the optimizing compiler performance is more than 1000/per second (my 2Ghz PC). The baseline JET compiler is ten times faster. Does harmony just load all the classes in the classlib and compile every method? If not, then why would there be so many methods compiled for a simple hello world program? Not Harmony does not load all the classes. Right now I am trying to write a simple profiling tool that counts the number of certain instructions in a program for a given input (i.e. I want to run the program, and for every instruction that ends up running, collect information). So, since it seems that the jit not only compiles every instruction in the program (not only the ones that end up running), but also a bunch of other classes, I thought perhaps I would be more interested in the interpreter. Interpreter also executes a lot of "startup methods" before running "main". There is a solution how to compile only predefined set of methods by separate JIT compiler. See EM guide for details how to filter methods: http://incubator.apache.org/harmony/subcomponents/drlvm/emguide.html The filters will not work with interpreter. Also, I am trying to become familiar with the jit and interpreter by reading the DRL Developer's Guide. Are there any other resources other than the Developer's Guide and this mailing list? Check these pages too: http://incubator.apache.org/harmony/subcomponents/drlvm/index.html http://wiki.apache.org/harmony/ or ask directly in the mailing list :) -- Mikhail Fursov
Re: [drlvm][classlib] thread library - let there be one!
What is the goal here? 1. If the goal is to create a single thread library that can be used by multiple VM and classlib implementations, then the unified thread lib should contain everything needed to support a VM implementation. 2. If the goal is to simply define the interface between the classlib and the VM, then the 3rd option may be acceptable. This option seems to imply splitting up functionality that requires deep knowledge of the threading implementation, which I don't like. Each VM implementation would need to implement both the VM and classlib sides of the API. Regards, Angela On 10/19/06, Artem Aliev <[EMAIL PROTECTED]> wrote: Angela, all, I see you point and agree. But if we move hythread lib to the VM we will require all VMs fully support it. Is it necessary dependency? So Here is the third way I see. Leave the minimum implementation of hythread in the classlib, with the set of functions any VM should provide for classlib. This will simplifies adopting classlib to new VM and allows to have solid threading model. So any VM could have its own super set of threading functions. Note: Classlib uses only monitor, TLS, and thread_create() from hythread. Thanks Artem On 10/18/06, Angela Lin <[EMAIL PROTECTED]> wrote: > Artem et al, > > Sorry for jumping in late here. > > I maintain the J9VM thread lib. > > Option 1 worries me because it implies that the classlib could use a > different threading model from the VM. This is bad because they both > operate on the same threads. > > For example: Layer (2) of hythread might include internal thread state > tracking, which is needed to support inspecting the thread state. > Using layer (1) directly would bypass the thread state tracking. > > Angela > > > On 10/16/06, Artem Aliev <[EMAIL PROTECTED]> wrote: > > Tim, > > > > Reading through discussion, I find two option for the second step. > > Let's discuss them. > > > > 1. > > > - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and > > > upper layer (hythead_xxx) > > > - migrate classlib code to the bottom layer (1) of hythread > > Then move the rest of hythread to VM. > > > > In this case we will move all VM releated functionality out of a classlib. > > The classlib will use tls, mutex and thread_create from *.h files. > > VM will be free to implement threading in any way. > > > > 2. Move hythread out from the drlvm to a portlib. > > In this case classlib will contains a lot of only VM releated code. > > So we will meet the same problems with an new VM. But we will have > > common place for all synchronization primitives and could control > > them. > > > > Thanks > > Artem > > > > > > > > > > > > On 10/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > > > > > > Tim Ellison wrote: > > > > First step (moving out of luni) looks good to me. > > > > > > > > I'd like some more discussion around the second step (picking up drlvm > > > > version) before you do a wholesale replacement. > > > > > > Yes please. Lets do small, reversible steps. > > > > > > geir > > > > > > > > > > > Regards, > > > > Tim > > > > > > > > Weldon Washburn wrote: > > > >> Artem, > > > >> Thanks. I will take a look. > > > >> > > > >> > > > >> On 10/12/06, Artem Aliev <[EMAIL PROTECTED]> wrote: > > > >>> Guys, > > > >>> > > > >>> > > > 1. Make classlib/modules/portlib directory (or portlib in the root?) > > > and move hyprt, hysig and hythread code into it. Update build to work > > > with new directory. > > > > > > > [Andrey]- pull out hythread from classlib, make it a shared > > > >>> component > > > >>> The first step is done in JIRA HARMONY-1843. > > > >>> > > > >>> I move common, pool, port, thread, sig from luni to new component > > > >>> portlib. > > > >>> The first idea was to move only port, thread, sig, but they depend on > > > >>> common and pool libs. It looks natural to do not produce cyclic > > > >>> dependencies among components, so I move these two also to portlib. > > > >>> > > > >>> Unfortunately, this does not fully solve two stage luni building > > > >>> process (build-native-core and build-native-secondary), but this is > > > >>> another problem. > > > >>> > > > >>> So If we are still committed on these reorganization, please review > > > >>> and apply the patch. > > > >>> > > > >>> A move_to_portlib.sh script create portlib directory structure and > > > >>> move appropriate files from luni to portlib (by svn move). > > > >>> A portlib_files.patch update build to works with new structure. > > > >>> > > > >>> Thanks > > > >>> Artem > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> On 9/29/06, Artem Aliev <[EMAIL PROTECTED]> wrote: > > > Guys, > > > > > > Let me try to make this changes. > > > > > > Here is my understanding of the steps I need to do. > > > > > > 1. Make classlib/modules/portlib directory (or portlib in the root?) > > > and move hyprt, hysig and hythread code into it. Update build to work > > > >>
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 from me. Our community seems to be very active and healthful. Best regards, 2006/10/20, Geir Magnusson Jr. <[EMAIL PROTECTED]>: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib][xnet] Problem connecting using SSLSocketImpl
Hi Gerald,
Boris and I resolved the problem. This was an incorrect "Certificate
Verify" message sent to the server peer during mutual authentication.
Please try the attached patch and tell us how it works. If it is OK
for you I will attach it to the JIRA report you created (when the
server will work). Please, note – this patch should be applied on the
current JSSE source versions (i.e. without early applied patches).
Actually Harmony supports PKCS12 keystore format. But there is an
issue with using it. We now work on this problem.
Thanks for your collaboration in making Harmony's JSSE Provider more
stable and robust! We really appreciate you support!
Regards,
Alexander Kleymenov
Index:
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/DigitalSignature.java
===
---
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/DigitalSignature.java
(revision 466004)
+++
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/DigitalSignature.java
(working copy)
@@ -71,6 +71,7 @@
public DigitalSignature(int keyExchange) {
try {
if (keyExchange == CipherSuite.KeyExchange_RSA_EXPORT ||
+keyExchange == CipherSuite.KeyExchange_RSA ||
keyExchange == CipherSuite.KeyExchange_DHE_RSA ||
keyExchange == CipherSuite.KeyExchange_DHE_RSA_EXPORT) {
// SignatureAlgorithm is rsa
Index:
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/ClientHandshakeImpl.java
===
---
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/ClientHandshakeImpl.java
(revision 466004)
+++
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/ClientHandshakeImpl.java
(working copy)
@@ -29,6 +29,7 @@
import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.NoSuchAlgorithmException;
+import java.security.PrivateKey;
import java.security.PrivilegedExceptionAction;
import java.security.PublicKey;
import java.security.cert.CertificateException;
@@ -366,6 +367,8 @@
* client messages, computers masterSecret, sends ChangeCipherSpec
*/
void processServerHelloDone() {
+PrivateKey clientKey = null;
+
if (serverCert != null) {
if (session.cipherSuite.keyExchange ==
CipherSuite.KeyExchange_DH_anon
|| session.cipherSuite.keyExchange ==
CipherSuite.KeyExchange_DH_anon_EXPORT) {
@@ -389,8 +392,10 @@
.getTypesAsString(),
certificateRequest.certificate_authorities, null);
if (clientAlias != null) {
-certs = ((X509ExtendedKeyManager) parameters.getKeyManager())
-.getCertificateChain((clientAlias));
+X509ExtendedKeyManager km = (X509ExtendedKeyManager) parameters
+.getKeyManager();
+certs = km.getCertificateChain((clientAlias));
+clientKey = km.getPrivateKey(clientAlias);
}
session.localCertificates = certs;
clientCert = new CertificateMessage(certs);
@@ -503,27 +508,29 @@
computerMasterSecret();
-if (clientCert != null) {
-boolean[] keyUsage = clientCert.certs[0].getKeyUsage();
-if (keyUsage != null && keyUsage[0]) {
-// Certificate verify
-DigitalSignature ds = new DigitalSignature(
-session.cipherSuite.keyExchange);
-if (session.cipherSuite.keyExchange ==
CipherSuite.KeyExchange_RSA_EXPORT
-|| session.cipherSuite.keyExchange ==
CipherSuite.KeyExchange_DHE_RSA
-|| session.cipherSuite.keyExchange ==
CipherSuite.KeyExchange_DHE_RSA_EXPORT) {
-ds.setMD5(io_stream.getDigestMD5());
-ds.setSHA(io_stream.getDigestSHA());
-} else if (session.cipherSuite.keyExchange ==
CipherSuite.KeyExchange_DHE_DSS
-|| session.cipherSuite.keyExchange ==
CipherSuite.KeyExchange_DHE_DSS_EXPORT) {
-ds.setSHA(io_stream.getDigestSHA());
-// The Signature should be empty in case of anonimous
signature algorithm:
-// } else if (session.cipherSuite.keyExchange ==
CipherSuite.KeyExchange_DH_anon ||
-// session.cipherSuite.keyExchange ==
CipherSuite.KeyExchange_DH_anon_EXPORT) {
-}
-certificateVerify = new CertificateVerify(ds.sign());
-send(certificateVerify);
+// send certificate verify for all certificates except those containing
+// fixed DH parameters
+if (clientCert != null && !clientKeyExchange.isEmpty()) {
+// Certificate verify
+DigitalSignature ds
Re: [drlvm] Using JNI methods in VM's components.
Mikhail, can relative path be specified in -Dvm.gc_dll/-Dvm.em_dll? If so, the path should be extended to represent full path. Regards, On 10/21/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: On 10/21/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > > This is the reason I've corrected the code. Doesn't it mean that is you > specified something in -Dvm.em_dll on command line that System.getProperty > would return non null value, and then you shall use System.load instead of > System.loadLibrary? That is if you change gc to em in the code above. Gregory, I have completely forgotten about System.load() and System.loadLibrary() differences. So the problem is solved and I have even tested the code :) -- Mikhail Fursov -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [classlib][luni] java.io.File bug?
Have you tested it on windows, for example, signing in as admin, and the
file which is set read only is still writable?:)
It is always good to follow RI or else we might encounter odd problems in
real applications.
Furthermore, "root" is the concept of OS, so I do not think the role should
be treated specially in the layer of java. We can delegate it to OS service
naturally if possible. I guess RI uses another implementation, for example,
the system call which itself deals with the user account.
On 10/20/06, Spark Shen <[EMAIL PROTECTED]> wrote:
Tony Wu 写道:
> you mean it fails when f.setReadOnly();?
Hi Tony:
No, setReadOnly is used to change the access privilege. After this
change harmony and RI behaves differently.
Best regards
>
> On 10/20/06, Spark Shen <[EMAIL PROTECTED]> wrote:
>> Hi All:
>>
>> When login as 'root' under Linux, the following test case fails on
>> Harmony while passes on RI.
>> public void test_canWrite() throws IOException{
>> File f = File.createTempFile("test", null);
>> f.setReadOnly();
>> assertTrue(f.canWrite());
>> f.deleteOnExit();
>> }
>>
>> I think RI's behavior is more reasonable since the 'root' account does
>> have read/write privilege for temp files. However, Harmony only treats
>> 'root' as ordinary other users.
>> It seems that similar problem happens on java.io.File.canRead().
>>
>> As we all know, File class deals with many different file object on
many
>> different file system, would any one test File behavior on other file
>> systems.
>>
>> Best regards
>>
>> --
>> Spark Shen
>> China Software Development Lab, IBM
>>
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
Spark Shen
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Leo Li
China Software Development Lab, IBM
Re: [vote] Graduate Apache Harmony podling from the Incubator
On 10/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status +1 Thanks, xiaofeng
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 Pavel Afremov. On 10/21/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: +1 On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > We're trying something a little different. I think Roy Fielding one > said something along the lines of "when a community gets organized > enough to vote itself out of the Incubator, it's appropriate." > > So to bring the Harmony community and the Incubator community together > for this important event in Harmony's life, I'm calling for a vote on > graduating Harmony here on our own -dev list. The objective is for all > in both the Harmony community and the Incubator community that have an > opinion to vote together, in the same place, and have it "hosted" by the > Harmony podling. > > This is an unconventional way to do this, but I think that it's valid > and could provide one example to the Incubator on how it can work going > forward. > > So, without any further ado : > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition the > board for Top Level Project status > > [ ] 0 No opinion > > [ ] -1 No, don't graduate Harmony. Here's why : > > > This vote will end 72 hours from now + time of Apache mail outage. It > will therefore end on Monday, October 23, at 3:30 PM eastern, + delta > for mail outage. > > Thanks > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Weldon Washburn Intel Middleware Products Division
[build] Problem with fetch-depends part of build script
Hello, This morning I have been trying to build Harmony and I'm having a problem with the fetch-depends part of the build script. I am getting the following output: Buildfile: *C:\eclipse32harmony\eclipse\workspace\Harmony\build.xml fetch-depends*: * -download*: [*echo*] Checking depends/jars/yoko-m1/yoko.jar * -really-download*: [*echo*] Fetching depends/jars/yoko-m1/yoko.jar [*get*] Getting: http://people.apache.org/maven-snapshot-repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M1-SNAPSHOT/yoko-spec-corba-1.0-incubating-M1-20060925.152805-4.jar [*get*] To: C:\eclipse32harmony\eclipse\workspace\Harmony\depends\jars\yoko-m1\yoko.jar [*get*] . [*get*] last modified = Thu Jan 01 01:00:00 GMT 1970 - using current time instead * -remove-file-if-bad*: BUILD FAILED * C:\eclipse32harmony\eclipse\workspace\Harmony\build.xml:275: The following error occurred while executing this line: C:\eclipse32harmony\eclipse\workspace\Harmony\make\depends.xml:158: The following error occurred while executing this line: C:\eclipse32harmony\eclipse\workspace\Harmony\make\depends.xml:248: ... * File depends/jars/yoko-m1/yoko.jar has incorrect md5 checksum. Expected: 87e62e170dd07cc9c31b9045395f3d10 found: 105a567dc9b27cbcaab4fe058021786e Total time: 2 minutes 8 seconds I have tried to run it a few times and also tried deleting the existing jars. Can anyone help with this problem? Thanks, Sian -- Sian January IBM Java Technology Centre, UK
Re: [drlvm][jit] Using Class.h in translator
Maksim, Am I right, that at the place you need to retrieve field from a class, you have both field's name AND descriptor? If so, you should move definion of FIeld* class_lookup_field_recursive(Class*, const char*, const char*) from vmcore/include/Class.h to include/jit_intf.h and change its prototype to accept Class_Handle instead of Class* and return Field_Handle instead of FIeld*. Also, please, change the implementation in C_Interface.cpp accordingly. Regards, Pavel. On 10/21/06, Maksim Ananjev <[EMAIL PROTECTED]> wrote: 21.10.06, Mikhail Fursov<[EMAIL PROTECTED]> wrote: > AFAIK the vm/vmcore/include/Class.h is vmcore internal header and was never > included in JIT. > To use its functionality you should declare the method you need in > vm/include/open/vm.h or in vm/include/open/*class*.h file Thanks! The way you described works! > What exact functionality do you need? I need to get field_desc of exact class having only the string name of this field. So I described special function in Class.h and defined it in Class.cpp. This method was a bit less painful on last version of Harmony build , but on actual version it caused severe сompilation errors. Such functionality I need in order to develop package of multidimensional arrays according to JSR-83 and have it optimized in JIT-compiler. The idea is to eliminate redundant boundchecks in a sort of way already implemented ABCD algorithm eliminates redundant boundchecks in one-dimensional arrays. (I wrote about this idea here some time ago) -- Maksim
[DRLVM][MMTk] current status and plan
Current status - Robin Garner's mmtk_20061016.zip snapshot of MMTk source now runs the simple "user-level" MarkSweep.java test on DLRVM svn HEAD of 10/20/2006. The mods to MMTk porting layer to support the above have been committed to DRLVM HEAD. The next steps for the MMTk/DRLVM port are as follows. Comments, suggestions are welcome. It would be much appreciated if Steve Blackburn and Robin Garner would reply to the questions below directed to the "MMTk guys". The following plan is roughly in the order this work should be done. - Currentlly MMTk/DRLVM runs as a "user-level" app. That is, MMTk port allocates a 450MB array from DRLVM's underlying GC. Currently only GCV4.0 supports 450MB arrays. A vmmagic "Address" object is created that points to the base of the 450MB array. MMTk is "booted" with the "Address" of the 450MB object. A simple MMTK exerciser was written in Java/vmmagic. It calls MMTk alloc() repeatedly. When MMTk runs out of memory, it will GC its "user-level" heap (the 450MB array). The underlying GCV4 is oblivious to what MMTK is doing with this 450MB array. - Project 1 - Move the existing MMTk port to GCV5. We need to remove the dependency on GCV4. - MMTk SemiSpace, GenMS and CopyMS collectors actually worked before upgrading to latest the MMTk sources and current DRLVM svn HEAD. - Project 2 - Get SemiSpace, GenMS and CopyMS collectors working again. Basically this means running TestSemiSpace.java, TestGenMS.java and TestCopyMS.java exerciser programs and debugging the problems. Known issues that need fixing: - Java write barrier in Jitrino.JET needs to be debugged - MMTk needs the two LSBs of one of the object header byte. This was somehow broken during the commit of BBC.patch. It needs to be fixed. There is email on this topic in harmony-dev. - To reduce confusion, all of MMTk java source code needs to be jitted before any MMTk methods are called. - Project 3 - Modify DLRVM classloader to force all MMTk classes to be loaded and all methods JITed before any classlib java code is executed. - The next step is to integrate MMTk in the early DRLVM boot process. The goal is to make sure all code the JIT generates will allocate out of the MMTk heap. This is a "chicken and egg" kind of problem since no JITed code can execute until DRLVM has a GC that is ready to support object allocation. Most likely we will use the MMTk notion of "ImmortalSpace" for early object allocation. Objects in ImmortalSpace are never collected, never moved. At this stage of MMTk/DRLVM porting, the cost of dead uncollected objects wasting ImmortalSpace memory is not a concern. - The existing MMTk/DRLVM porting layer is in rough shape and is incomplete. Now would be a good time to take another pass at refining the porting layer. Below are notes on fixing the porting layer which is located at: drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk - Project 4 - Assert class - This class currently causes a Null Pointer Exception to force a stack trace in each and every method. Unfortunately this means MMTk always crashes even in situations where execution is supposed to continue. Some of the APIs supposed to print the stack trace then continue execution. This needs to be fixed. - Barriers class - performWriteInBarrier() – MMTk expects to perform both the write of an object slot as well as the write barrier. The existing contract between Jitrino, VM and the GC expects that the JIT will write on the object slot then separately call the write barrier api (I think). In any case, if the JIT is still writing on the object slot, it needs to be changed to let the MMTk inlined support function to do it. - performWriteInBarrierAtomic() – this needs to be implemented (its not really needed until much later when multithread support is turned on.) - setArrayNoBarrier() – need to write some simple vmmagic code that will set an element of an array of objects without triggering a write barrier. This support is required by MMTk internal functions to prevent endless write barrier recursion. - Collection Class - triggerCollection() method needs to be connected to the Java API that forces a GC (this is low priority) - prepareMutator() method probably needs to be integrated with back-branch polling mechanism. Also need to confirm the requirement that a thread suspend request does indeed force the target thread to be suspended at a GC safepoint. (MMTk guys, can you confirm this?) - prepareCollector() method – Its not clear MMTk/DRLVM needs to do anything. (MMTk folks ple
Re: [classlib][test] Configuration dependent test of InetAddress.getHostName
I think Harmony does the right thing as spec requires, the difference is
caused by underlying system call, so it should be acceptable, i.e., the
test needs to be rewritten or excluded.
+1 from me
Thanks,
2006/10/20, Paulex Yang <[EMAIL PROTECTED]>:
Denis Kishenko wrote:
> I have researched issue H-1664 and found one more difference with RI.
> I run simple test on Windows Server 2003 SP1
>
> === Test =
> import java.net.InetAddress;
> import java.net.UnknownHostException;
>
> public class Test {
>public static void main(String[] args) throws UnknownHostException {
>System.out.println("by name (127.0.0.1) -> " +
> InetAddress.getByName("127.0.0.1").getHostName());
>System.out.println("by name (localhost) -> " +
> InetAddress.getByName("localhost").getHostName());
>System.out.println("by address -> " +
> InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
>System.out.println("localhost -> " + InetAddress.getLocalHost());
>}
>
> }
>
> Windows Server 2003 SP1
> === RI ==
>by name (127.0.0.1) -> 127.0.0.1
>by name (localhost) -> localhost
>by address -> 127.0.0.1
>localhost -> nstdrlew21/10.125.122.60
>
> = Harmony ==
>by name (127.0.0.1) -> nstdrlew21.ins.intel.com
>by name (localhost) -> localhost
>by address -> nstdrlew21.ins.intel.com
>localhost -> nstdrlew21/10.125.122.60
>
> WinXP
> = Both ===
> by name (127.0.0.1) -> localhost
> by name (localhost) -> localhost
> by address -> localhost
> localhost -> pbwdmkishen/10.125.132.226
>
>
> Actually Harmony use native call of getnameinfo() to get host name
> (which is reasonable IMHO). MSDN says "The getnameinfo function
> provides name resolution from an address to the host name".
>
> InetAddressTest.test_getHostName (see H-1664) failed on WinServer
> because InetAddress.getByName("127.0.0.1").getHostName() returned
> "nstdrlew21.ins.intel.com" while "localhost" expected. So this test
> looks like configuration dependent.
>
> I see three possible options
> 1. Stay test as is. Just keep in mind that on specific configurations
> this one fails.
> 2. Rewrite test to be configuration dependent. Test has to do the same
> native call.
> 3. Exclude localhost checking from test_getHostName.
I think Harmony does the right thing as spec requires, the difference is
caused by underlying system call, so it should be acceptable, i.e., the
test needs to be rewritten or excluded. But this issue worth a non-bug
difference together with getHostName()'s different behavior when
SecurityManager presents[1](thanks Alexei Fedotov helped to find this
link and commented to HARMONY-1664:))
Harmony-73 is another issue, which is actually caused by HARMONY-84 and
irrelevant with getHostName() method.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL
PROTECTED]
>
> What do you think about this situation?
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [drlvm] Calling native methods from Java code: implementation details
Hi.
On First question I think that alternative 1 is better. It's allow to avoid
creating of "special" or "magic" registration subsystem which should
provide addresses for "magic" native call.
On the Second question I agree with Pavel P. Null should be OK.
On Third question, I think no additional actions is required. All dll's or
so's for DRL VM must be in jre/bin directory and classes jar's must be
jre/lib directory. Both should be loaded by as the others in these
directories now. It's the first part of "third" question. The second part
or "fourth" question is "How to understand that this class contains magic
native functions?". I prefer answer by extends a special empty interface.
It's can provide opportunity writing libraries with fast native calls in
future. Also it's match with java security. DRL VM can control what
component can use "Magic" and what not via SecurityManager.
Mikhail could you summarize all issues which should be clarified and
possible solutions for these issues?
Thanks.
Pavel Afremov.
On 10/20/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
Prerequisite: each component carries its own helpers (which means no
"allocation helper" in VM Core, for example).
Yes, simple JIT will call helper as regular JNI method.
I missed several issues in my original message.
First: "how to get address of helper?"
Answer:
Two choices:
1) each component must provide "static native long getHelperAddress(int)"
in
its helper class. JIT will make a call to this function as regular JNICALL
(stdcall on Windows, cdecl on Linux). Function prototype can be typedef'ed
as "typedef (JNICALL*)(JNIEnv*, jint)". The issue I see here is naming:
each
component has its own helpers class name. So, the name for native method
to
call will be __getHelperAddress.
2) add regular (OPEN) interface function to each component which will
provide such mapping (as it is now done by VM).
Second: "what should be passed as JNIEnv to getHelperAddress?"
Answer:
NULL. Component should not use JNIEnv pointer in this call.
Third: "how to retrieve helpers class for a particular component?"
Answer:
Two choices again:
1) component modifies boot class path on initialization and exports
.helpers_class system property. Then VM loads this class
and
JIT uses this class' name to retrieve fast path helpers.
2) component exports .helpers_jar system property on
initialization, then VM adds this JAR to boot class path, extracts the
manifest from it, retrieve Helpers-Class attribute from the manifest, and
exports it as .helpers_class. Then VM loads this class and
JIT uses this class' name to retrieve fast path helpers.
I, personally, prefer second choice here.
Anything else?..
Pavel.
On 10/20/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
> Pavel Pervov :
> > My alternative follows:
> >
> > 1) Each component which exports magics, provides JAR file with class
> > implementing these magics. Class name is described in (e.g.)
Main-Class
> > attribute of JAR's manifest.
> > 2) The class contains java fast path for helper, and a pair of native
> > methods: one for fast-slow path, and one for slow-slow path.
> > 3) Fast-slow path helper can have any (supported) calling convention.
>
>
> > 4) Slow-slow path helper will be called through JNI - it is regular
> native
> > method.
> ...
> > way and generate call to slow_alloc in annotated calling convention.
> If JIT
> > does not support magics at all, it'll call jni_alloc in usual way - as
> > regular call to native Java method.
>
>
> Helpers are neither called as JNI methods nor they are called through
> the JNI.
>
> Or do you propose to make a code for the helpers as the JNI methods?
> How would the 'jni_alloc(Address class, int size);' look like in the C
> code?
>
>
>
> --
> Thanks,
> Alex
>
>
>
> >
> > The example follows:
> > --
> > package org.apache.harmony.vm.helpers;
> > // Annotations follow here, which describe which method is which
helper,
> > // and which is fast-path, fast-slow path, slow-slow path
> > class GCv6Helpers {
> >// fast-path allocation here
> >public static Address alloc(Address class, int size) {
> >// ...
> >}
> >// annotation, describing calling convention for fast-slow path
> >public static native Address slow_alloc(Address class, int size);
> >public static native Address jni_alloc(Address class, int size);
> > }
> >
> > Now, if JIT supports magics, it'll process GCv6Magics::alloc in a
> special
> > way and generate call to slow_alloc in annotated calling convention.
If
> JIT
> > does not support magics at all, it'll call jni_alloc in usual way - as
> > regular call to native Java method.
> >
> > Yes, my idea suggests to change helper retrieval interface for JIT,
but
> we
> > already started to make significant changes to architecture - let's
just
> > make them more generic.
> >
> > Regards,
> >Pavel.
> >
> > P.S. IMHO, this approach combines strong sides of Mikhail's and
Pavel's
> > ideas, as it use s
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 from me let's make things better On 10/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert Hu China Software Development Lab, IBM
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
I haven't had a chance to look at the issue (JIRAs down right now, probably part of the infrastructure move), but have you tried comparing the actual class files of the problematic class or classes. I'd suggest compiling the files using ECJ, save them off, compile with Sun/BEA/etc, save them off and then run javap from a single JDK on each of the class files and compare them for differences. -Nathan On 10/21/06, Elena Semukhina <[EMAIL PROTECTED]> wrote: Hi all, after classlib build system has switched to use ECJ, one test in swing module started to fail on drlvm (win/linux). Actually the failure is not related to swing functionality. I've filed JIRA issue https://issues.apache.org/jira/browse/HARMONY-1931 and attached a simple test to reproduce the failure. All interested parties are welcome to look at this issue! -- Thanks, Elena
Re: [classlib][luni] signalis interruptus in hysock
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And after every N loops, print a warning/diagnostic message. The
value for N would have to be tuned. I don't know what the best number would
be. Given that 1904 patch is not the final solution, at least a diagnostic
that hints at where the system hangs would be useful. It might make sense
to even print a stack trace. Also, I agree with Ivan below. Signals bugs
are very hard to debug. And diagnostics can help us all understand the
corner cases better.
On 10/20/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> Ivan Volosyuk wrote:
> > Well, I think that the solution is what Geir suggests. One think which
> > bothers me is following. EINTR can happen in different places and the
> > situations can be quite rare in some circumstances. It can lead to
> > hard to reproduce stability bugs (race conditions).
>
> Can you give an example?
Half a year ago, I was working on the problem. Socket operations get
sometimes interrupted. We have found out that it occurs sometime after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have rock
solid support of EINTR handling everywhere the select(), poll() calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
>
> > We should find a
> > way how to test the implementation.
>
> +1!
>
> :)
>
> geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
RE: [jira] Commented: (HARMONY-632) Patch to provide parsing of file_bands at end of Pack200 file.
Alex, I believe only committers can close an issue. Once an issue is resolved, I usually leave a comment and ask the reporter to verify it and then when that happens I close it. It's not uncommon that verification just gets missed, so I just come back and close anything that has been resolved for a month or longer. -Nathan -- Forwarded message -- From: Alex Blewitt (JIRA) <[EMAIL PROTECTED]> Date: Oct 21, 2006 5:12 AM Subject: [jira] Commented: (HARMONY-632) Patch to provide parsing of file_bands at end of Pack200 file. To: [EMAIL PROTECTED] [ http://issues.apache.org/jira/browse/HARMONY-632?page=comments#action_12444028 ] Alex Blewitt commented on HARMONY-632: -- Sorry, what's the correct protocol for these situations? Do I need to comment that all is OK and then close it, or can you only close it? Patch to provide parsing of file_bands at end of Pack200 file. -- Key: HARMONY-632 URL: http://issues.apache.org/jira/browse/HARMONY-632 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Alex Blewitt Assigned To: Nathan Beyer Priority: Trivial Attachments: segment.patch This patch provides the unpacking of the file_bands at the end of a Pack200 archive. With this, the implementation is now capable of reading a non-GZipped pack200 archive and being able to correctly extract the file names and bytes. Currently, the parsing does no processing in terms of being able to reconstitute those into files. Owing to a Java limitation in byte array initialisation, the maximum size of a file must be <2Gb in this current implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [build] ant help needed
Actually it would be easy to inspect the unresolvable
reference name, and if it were in ${.*} format
(meaning it is an unexpanded property reference) issue
a warning... I'll think on that. ;)
-Matt
--- Tim Ellison <[EMAIL PROTECTED]> wrote:
> On 20/10/06, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > That's because you tried to use property expansion
> > notation--"${hy.required.metainf-files}"--for a
> > reference. Try
> >
> >
>
> When do we get support for the option?
>ant --do-what-I-mean-not-what-I-say :-)
>
> Thanks, will try again when my machine is
> serviceable.
>
> Tim
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 On 21/10/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: +1 On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > We're trying something a little different. I think Roy Fielding one > said something along the lines of "when a community gets organized > enough to vote itself out of the Incubator, it's appropriate." > > So to bring the Harmony community and the Incubator community together > for this important event in Harmony's life, I'm calling for a vote on > graduating Harmony here on our own -dev list. The objective is for all > in both the Harmony community and the Incubator community that have an > opinion to vote together, in the same place, and have it "hosted" by the > Harmony podling. > > This is an unconventional way to do this, but I think that it's valid > and could provide one example to the Incubator on how it can work going > forward. > > So, without any further ado : > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition the > board for Top Level Project status > > [ ] 0 No opinion > > [ ] -1 No, don't graduate Harmony. Here's why : > > > This vote will end 72 hours from now + time of Apache mail outage. It > will therefore end on Monday, October 23, at 3:30 PM eastern, + delta > for mail outage. > > Thanks > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Weldon Washburn Intel Middleware Products Division -- Sian January IBM Java Technology Centre, UK
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 On 10/22/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: +1 On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > We're trying something a little different. I think Roy Fielding one > said something along the lines of "when a community gets organized > enough to vote itself out of the Incubator, it's appropriate." > > So to bring the Harmony community and the Incubator community together > for this important event in Harmony's life, I'm calling for a vote on > graduating Harmony here on our own -dev list. The objective is for all > in both the Harmony community and the Incubator community that have an > opinion to vote together, in the same place, and have it "hosted" by the > Harmony podling. > > This is an unconventional way to do this, but I think that it's valid > and could provide one example to the Incubator on how it can work going > forward. > > So, without any further ado : > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition the > board for Top Level Project status > > [ ] 0 No opinion > > [ ] -1 No, don't graduate Harmony. Here's why : > > > This vote will end 72 hours from now + time of Apache mail outage. It > will therefore end on Monday, October 23, at 3:30 PM eastern, + delta > for mail outage. > > Thanks > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Weldon Washburn Intel Middleware Products Division -- Tony Wu China Software Development Lab, IBM
Re: [drlvm] Calling native methods from Java code: implementation details
Hi
Alex my answer is inline:
On 10/20/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
Helpers are neither called as JNI methods nor they are called through
the JNI.
Or do you propose to make a code for the helpers as the JNI methods?
How would the 'jni_alloc(Address class, int size);' look like in the C
code?
Yes. Current slow path call is very simular to JNI.
It's can be looks like:
jni_alloc(jclass clss) {
hythread_suspend_disable();
Class* c = jni_get_class_handle(clss)
ManageObject obj = class_alloc_new_object(Class *c);
ObjectHandle obj_handle = NULL;
if (NULL != obj) {
obj_handle = oh_allocate_global_handle();
}
hythread_suspend_enable();
return obj_handle;'
}
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1, It's cl! :) Geir Magnusson Jr. wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > We're trying something a little different. I think Roy Fielding one > said something along the lines of "when a community gets organized > enough to vote itself out of the Incubator, it's appropriate." > > So to bring the Harmony community and the Incubator community together > for this important event in Harmony's life, I'm calling for a vote on > graduating Harmony here on our own -dev list. The objective is for all > in both the Harmony community and the Incubator community that have an > opinion to vote together, in the same place, and have it "hosted" by the > Harmony podling. > > This is an unconventional way to do this, but I think that it's valid > and could provide one example to the Incubator on how it can work going > forward. > > So, without any further ado : > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition the > board for Top Level Project status > > [ ] 0 No opinion > > [ ] -1 No, don't graduate Harmony. Here's why : > > > This vote will end 72 hours from now + time of Apache mail outage. It > will therefore end on Monday, October 23, at 3:30 PM eastern, + delta > for mail outage. > > Thanks > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Weldon Washburn Intel Middleware Products Division
Re: svn commit: r466154 - in /incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent: ./ locks/
This can be controlled a bit more. An svn:externals link can point to a specific revision, not just a SVN URL. This way the working copy download has to be changed at the point of link. -Nathan On 10/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Great - I wanted to make sure. I was asking based on a cursory glance. geir Nathan Beyer wrote: > They are in 'standard' and do use 'links' (svn:externals). Check out > the full path of the original commit message. Using svn:externals just > makes it seem like it's in 'extended', but that's just in your working > copy. > > -Nathan > > On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> Thanks for bringing this up. I did a classlib update this morning, and >> saw these files change, and I was confused. >> >> Why do we have the files here anyway? I thought we were going to keep >> in /standard and use links? >> >> geir >> >> Tim Ellison wrote: >> > Mark, >> > >> > I suggest that this is rolled back since it is modifying the >> concurrency >> > code in our 'standard' SVN area that we aim to keep in close sync with >> > Doug's repository. >> > >> > Perhaps we can offer the patch to that community, and/or set up local >> > compiler options to hide the warnings in this module. >> > >> > Regards, >> > Tim >> > >> > [EMAIL PROTECTED] wrote: >> >> Author: hindessm >> >> Date: Fri Oct 20 08:47:50 2006 >> >> New Revision: 466154 >> >> >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=466154 >> >> Log: >> >> Applied two patches from "[#HARMONY-1926] [build] A lot of "never >> used" >> >> and "never read" warning messages". >> >> >> >> Modified: >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ArrayBlockingQueue.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ConcurrentHashMap.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/CountDownLatch.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/DelayQueue.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Delayed.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ExecutorService.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Executors.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/FutureTask.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ScheduledExecutorService.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Semaphore.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/SynchronousQueue.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/AbstractQueuedSynchronizer.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/LockSupport.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/ReentrantLock.java >> >> >> >> incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/ReentrantReadWriteLock.java >> >> >> >> > >> > >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >
Harmony passes 94% on derby tests.
467 Tests Run 94% Pass (443 tests passed) 6% Fail (24 tests failed) 5 Suites skipped The main progress focuses here: 1. Harmony classlib fails to load class when user-defined security policy exists. It is due to the sequence of library loading of VM, which has been resolved now. 2. A new workround for derby tests which allow useprocess to run test or else several testcases might fail due to derby lack these tests when useprocess = false. 3. Derby source code uses the version and the name of java vm to decide what to do, while current IBM VM has the version of "1.4.2" and the name of "j9", which has different output on the screen from that of standard RI 1.5. At the same time Derby test compares the output of the iteractive test scripts to that of expected. I have made some slight modification in its source code, but I have not throughly change this odd behavior, ...,too much:( Besides, some testcase fails even on RI. I exclude a "derbynetclientmats" test suit since it will hang both RI and Harmony. Currently all the failure is irrelevant to Harmony. Hope I can find something in the left. I have updated the wiki of derby on Hamony: http://wiki.apache.org/harmony/Apache_Derby. -- Leo Li China Software Development Lab, IBM
RE: RE: Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful
>-Original Message- >From: Alex Blewitt [mailto:[EMAIL PROTECTED] >Sent: Saturday, October 21, 2006 3:32 AM >To: harmony-dev@incubator.apache.org >Subject: Re: RE: Thoughtless fixes considered harmful Was: [OT] Automated >fixes considered harmful > >On 21/10/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote: >> Alex, >> I see and accept your point. I believe that partial commits are a must - >> we should be a community. >> >> My point is simple - the code under active development shouldn't be a >> subject of beautification - it just should be safe for other Harmony >> modules. The first goal is to make it work. > >Completely agree. Code which is fluctuating under development >shouldn't cause a concern that it's generating warnings for this kind >of thing. > >Once the code matures, and is fully implemented and tested, *then* >that's the time to start the beautification process :-) > I agree with this too. No beautification should be performed on code which is actively being developed. I think everybody understands it clearly. But once the code is quite stable and only bug fixes are applied to it, I see no harm from deleting unused local variables and imports. Removing unreferenced private fields and methods can be dangerous. Nevertheless I'd vote for removing ones as well. It makes code more concise leaving no legacy. Regards, -- Alexey A. Ivanov Intel Middleware Product Division
Re: [vote] Graduate Apache Harmony podling from the Incubator
On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: [X] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status the community still has things to learn about the release process (see http://mail-archives.apache.org/mod_mbox/incubator-general/200610.mbox/[EMAIL PROTECTED], for example) but IMHO the community should prove strong enough to face successfully these challenges. (and - with a little bit of luck - the documentation and tools available should be a little better by then...) - robert
RE: [vote] Graduate Apache Harmony podling from the Incubator
+1 Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 11:30 PM To: harmony-dev@incubator.apache.org Subject: [vote] Graduate Apache Harmony podling from the Incubator We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Congratulations! Great news! Sorry for being a bit outdated - I was on vacations last week. On 10/18/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: Congratulations to all the new committers. -N On 10/16/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > Please join the Apache Harmony PPMC in welcoming the project's newest > committers, in alphabetical order : > > Oliver Deakin > Richard Liang > Alexey Petrenko > Gregory Shimansky > Alexey Varlamov > Alexei Zakharov > > These six individuals have shown sustained dedication to the project, an > ability to work well with others, and share the common vision we have > for Harmony. We all continue to expect great things from them. > > Gentlemen, you don't have accounts yet. When you finally receive your > new committer account information, as a first step to test your almighty > powers of committitude, please update the committers page on the > website. That should be a good (and harmless) exercise to test if > everything is working. > > Things to do : > > 1) test ssh-ing to the server people.apache.org. > 2) Change your login password on the machine > 3) Add a public key to .ssh so you can stop using the password > 4) Set your SVN password : just type 'svnpasswd' > > At this point, you should be good to go. Checkout the website from svn > and update it. See if you can figure out how. > > Also, anything checked out of SVN, be sure that you have checked out via > 'https' and not 'http' or you can't check in. You can switch using "svn > switch". (See the manual) > > Finally, although you now have the ability to commit, please remember : > > 1) continue being as transparent and communicative as possible. You > earned committer status in part because of your engagement with others. > While it was a "have to" situation because you had to submit patches > and defend them, but we believe it is a "want to". Community is the key > to any Apache project. > > 2)We don't want anyone going off and doing lots of work locally, and > then committing. Committing is like voting in Chicago - do it early and > often. Of course, you don't want to break the build, but keep the > "commit bombs" to an absolute minimum, and warn the community if you are > going to do it - we may suggest it goes into a branch at first. Use > branches if you need to. > > 3) Always remember that you can **never** commit code that comes from > someone else, even a co-worker. All code from someone else must be > submitted by the copyright holder (either the author or author's > employer, depending) as a JIRA, and then follow up with the required > ACQs and BCC. > > Again, thanks for your hard work so far, and welcome. > > The Apache Harmony PPMC > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm][jit] Seems like too many classes loaded
I am trying to become more familiar with the jit code. I ran the following to see what all was compiled when running Hello World. "java -Xtrace:compile Hello". I was very surprised to see the number of methods that seem to be loaded. I think there are about 1079 methods that get compiled for Hello World. Does harmony just load all the classes in the classlib and compile every method? If not, then why would there be so many methods compiled for a simple hello world program? Right now I am trying to write a simple profiling tool that counts the number of certain instructions in a program for a given input (i.e. I want to run the program, and for every instruction that ends up running, collect information). So, since it seems that the jit not only compiles every instruction in the program (not only the ones that end up running), but also a bunch of other classes, I thought perhaps I would be more interested in the interpreter. Running "java -Xint -Xtrace:interpreter Hello" then also gave me way more output then I expected. For example ... interpreter: java/lang/String indexOf(II)I interpreter: java/lang/String startsWith(Ljava/lang/String;)Z interpreter: java/lang/String startsWith(Ljava/lang/String;I)Z interpreter: java/lang/String regionMatches(ILjava/lang/String;II)Z interpreter: java/net/URI access$1002(Ljava/net/URI;Ljava/lang/String;)Ljava/lang/String; interpreter: java/net/URI access$1000(Ljava/net/URI;)Ljava/lang/String; interpreter: java/net/URI$Helper validatePath(Ljava/lang/String;Ljava/lang/String;I)V interpreter: java/net/URIEncoderDecoder validate(Ljava/lang/String;Ljava/lang/String;)V interpreter: java/lang/String length()I interpreter: java/lang/String charAt(I)C interpreter: java/lang/String indexOf(I)I interpreter: java/lang/String indexOf(II)I interpreter: java/lang/String length()I ... I'm not sure why all of this is being interpreted for a simple hello world program. My understanding was that the interpreter traverses the byte code for the given input and then handles the executed byte codes. It seems like a lot more is going on here. Also, I am trying to become familiar with the jit and interpreter by reading the DRL Developer's Guide. Are there any other resources other than the Developer's Guide and this mailing list? Thanks Armand
Re: [vote] Graduate Apache Harmony podling from the Incubator
+ 1. ;-) Best regards, Richard On 10/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Development Lab, IBM
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1
Re: [drlvm] A list of drlvm enhancements and limitations
All, Just a few minutes ago I sent a mail titled, "[DRLVM][MMTk]" current status and plan". It is way too long and detailed to include in this list of drlvm enhancements. Below is a summary that hopefully is at the appropriate level of detail. Please refer to the above email for more information. Summary of MMTk projects 1) Move the exiting "uswer-level" MMTk port to GCV5 2) Get MMTk SemiSpace, GenMS and CopyMS collector running again. They were broken during migration to latest MMTk source and latest drlvm svn HEAD. 3) Alter DRLVM classloader to force all MMTk classes to be loaded and all methods to be JITed before any java code is executed. Integrate MMTk into an early stage of DRLVM boot. 4) Fix up MMTk/VM porting layer which is located at: drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk 5) Debug and verify JIT support for MMTk's Uninterruptible class. Run simple multithread app and debug. On 10/17/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: Hi Gregory, It is a good idea to put up a live list, thanks. Here are some suggestions on the contents for development items in the VM/JIT. A few may be almost done. We can fine tune...and add other work items as well - MMTk integration: Support for magic classes in Jitrino VM/JIT support for MMTk collectors including RSE and thread suspension ( Weldon, could you please add details?) Thanks > On 10/16/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > Once it's more or less ready let's point to that page from TODO on our > > website > > > > Thanks, > > Mikhail > > > > 2006/10/17, Gregory Shimansky <[EMAIL PROTECTED]>: > > > Hello > > > > > > You know that drlvm was donated by Intel and there was some period of > > time > > > while drlvm was developed internally. We had an internal bugzilla > > server to > > > track the issues. In an effort to move all development to the open > > this > > > internal bugzilla will be closed. > > > > > > The database is quite big and contains a lot of valuable information > > including > > > still open bugs. There are many of them which are not exactly bug > > reports, > > > but requests for enhancements or limitation problems. These small > > issues > > > didn't make it to README because they are mostly minor and low > > priority, but > > > it is better to use information which we have already than rediscover > > these > > > problems again. > > > > > > So not to create a lot of garbage in JIRA like problem requests > > without > > > patches I think it is better to create something like a TODO list for > > drlvm. > > > Not exactly bugs, but more like known limitations list. > > > > > > To give you an example, vm/vmcore/src/init/properties.cpp contains a > > #define > > > MAX_PROP_LINE 5120 which is a maximum property length specified in > > > vm.properties file. I am not even sure if this file still used, > > probably not, > > > but a buffer length limitation is still a bad thing. > > > > > > I think a good place for such list would be on wiki. I am going to > > create a > > > page for it so that everyone who has open bugs inside of Intel could > > add a > > > line or two describing a problem recorded in bugzilla. I have 3 like > > these > > > filed myself including the one I gave as an example. > > > > > > I don't know the number of such bugs overall, maybe it is not so big. > > But > > > before creating JIRAs for them I think it is better to collect a list > > on > > > wiki. What do you think? > > > > > > -- > > > Gregory Shimansky, Intel Middleware Products Division > > > > > > -- Weldon Washburn Intel Middleware Products Division
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 Geir Magnusson Jr. 写道: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM
RE: [vote] Graduate Apache Harmony podling from the Incubator
+1 Dan Lydick > [Original Message] > From: Geir Magnusson Jr. <[EMAIL PROTECTED]> > To: > Date: 10/20/06 2:30:42 PM > Subject: [vote] Graduate Apache Harmony podling from the Incubator > > We're trying something a little different. I think Roy Fielding one > said something along the lines of "when a community gets organized > enough to vote itself out of the Incubator, it's appropriate." > > So to bring the Harmony community and the Incubator community together > for this important event in Harmony's life, I'm calling for a vote on > graduating Harmony here on our own -dev list. The objective is for all > in both the Harmony community and the Incubator community that have an > opinion to vote together, in the same place, and have it "hosted" by the > Harmony podling. > > This is an unconventional way to do this, but I think that it's valid > and could provide one example to the Incubator on how it can work going > forward. > > So, without any further ado : > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition the > board for Top Level Project status > > [ ] 0 No opinion > > [ ] -1 No, don't graduate Harmony. Here's why : > > > This vote will end 72 hours from now + time of Apache mail outage. It > will therefore end on Monday, October 23, at 3:30 PM eastern, + delta > for mail outage. > > Thanks > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Hi I've developed two "impossible" tests, which shows "fake" circularity errors. One test is more simple and use SecurityManager. The other is a bit more complex and uses custom ClassLoader. You can find them in attachment. Thanks. Pavel Afremov On 10/17/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: The scenario I described earlier is impossible. Resolution of any classreferenced in some other class is performed by class loader, which loaded that other class. So, no chance to load "A" and referencing class loader(UCL) with this UCL.Sorry for confusion.Regards, Pavel.P.S. Still there are concerns why lazy resolution should be supported by JITs. But it is absolutely another story.On 10/17/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:>> IMO we shall be between BEA and SUN: to work if both RI work, to fail if > both RI fail and discuss each test in details if only one RI passes.>> On 10/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:> >> > On Friday 13 October 2006 08:04 Alexey Varlamov wrote: > > > I'm curious, if we enable "controlled" recursion in classloading -> > > will it resolve this kind of issues completely? I'm pretty sure it> > > would resolve at least some scenarios - like the one Pavel described > > > for gc.Finalizers or a case of classloading initiated within> > > SecurityManager.checkPermission() which we also faced not once.> > > "Controlled" recursion here means counting depth of recursion and > > > allowing at least 1 recursive iteration. I've seen some tricks in> > > URLClassLoader which assume such ability, but they do not work with> > > DRLVM.> >> > I think it is different. URLClassLoader is system class which is loaded > by> > bootstrap, so no recursion happens for classes which it itself requires> to> > be> > loaded when it is being compiled.> >> > > For the pure user code scenario Pavel suggested above, there may be > > > some nuances leading to truly endless recursion, but still we need to> > > look at particular test first.> >> > It is not endless but it is definitely more than 1 level deep. If user > > sets up> > his own class loaders, compiling them may trigger loading some of the> user> > classes which are in turn loaded by class loaders set up by user. Shall> we> > then throw "NoClassDefFoundError: Class loading recursion limit reached. > > Please rewrite your code"? :)> >> > --> > Gregory Shimansky, Intel Middleware Products Division> >> > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html> > To unsubscribe, e-mail: [EMAIL PROTECTED]> > For additional commands, e-mail: [EMAIL PROTECTED]> >> > >>> --> Mikhail Fursov>>
RE: [vote] Graduate Apache Harmony podling from the Incubator
+1 -- Alexey A. Ivanov Intel Middleware Product Division >-Original Message- >From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] >Sent: Friday, October 20, 2006 11:30 PM >To: harmony-dev@incubator.apache.org >Subject: [vote] Graduate Apache Harmony podling from the Incubator > >We're trying something a little different. I think Roy Fielding one >said something along the lines of "when a community gets organized >enough to vote itself out of the Incubator, it's appropriate." > >So to bring the Harmony community and the Incubator community together >for this important event in Harmony's life, I'm calling for a vote on >graduating Harmony here on our own -dev list. The objective is for all >in both the Harmony community and the Incubator community that have an >opinion to vote together, in the same place, and have it "hosted" by the >Harmony podling. > >This is an unconventional way to do this, but I think that it's valid >and could provide one example to the Incubator on how it can work going >forward. > >So, without any further ado : > >[ ] +1 Graduate Apache Harmony from incubation, and let it petition the >board for Top Level Project status > >[ ] 0 No opinion > >[ ] -1 No, don't graduate Harmony. Here's why : > > >This vote will end 72 hours from now + time of Apache mail outage. It >will therefore end on Monday, October 23, at 3:30 PM eastern, + delta >for mail outage. > >Thanks > >geir > > >- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 This is a great news! On 21/10/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: +1 On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > We're trying something a little different. I think Roy Fielding one > said something along the lines of "when a community gets organized > enough to vote itself out of the Incubator, it's appropriate." > > So to bring the Harmony community and the Incubator community together > for this important event in Harmony's life, I'm calling for a vote on > graduating Harmony here on our own -dev list. The objective is for all > in both the Harmony community and the Incubator community that have an > opinion to vote together, in the same place, and have it "hosted" by the > Harmony podling. > > This is an unconventional way to do this, but I think that it's valid > and could provide one example to the Incubator on how it can work going > forward. > > So, without any further ado : > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition the > board for Top Level Project status > > [ ] 0 No opinion > > [ ] -1 No, don't graduate Harmony. Here's why : > > > This vote will end 72 hours from now + time of Apache mail outage. It > will therefore end on Monday, October 23, at 3:30 PM eastern, + delta > for mail outage. > > Thanks > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Weldon Washburn Intel Middleware Products Division -- Best regards, Pavel Rebriy
