Re: [vmi] passing -X options to VM
Checked -Xem:opt/jet/.. - works fine. The old format had a space between -Xem and config name. The new format is reasonable because it's more RI-like, but help message on -X option in DRLVM still contains parameters formatting like: -Xstats mask -Xgc gc options -Xem em options -Xdumpfile file I going to file a JIRA issue about this problem is nobody minds.. On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 20, 2006, at 11:22 AM, Egor Pasko wrote: On the 0x1EA day of Apache Harmony Mikhail Fursov wrote: On Sep 19, 2006, at 11:02 AM, Tim Ellison wrote: Geir Magnusson Jr. wrote: snip I'm going to modify the launcher to pass -help into the VM when it's been named java* so that it behaves like the tools that come with the Sun's, BEA's and IBM's impelmentation. All, What is the default behaviour of the launcher for -X options? I have found that -Xem option is not passed to VM anymore. I propose to pass all of -X options from the launcher to VM. Are there any potential problems in this solution? makes sense! Today we have our workaround like this: -Dem.properties=server_static That's weird. The launcher doesn't care. I thought I've used -Xem as in -Xem:something geir - 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: [classlib]build failed on windows
Leo Li wrote: Dear Geir: I advise to use -Werror in Linux compiling but I am not sure of the side-effect. I am now trying to know whether all the warning can be fixed in Linux.:) Volunteer is welcome:). If the errors number is too large to be fixed in one run, I suggest to fix them one module by another. On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Sorry. My fault. Fixing now. I need to find settings to make gcc on linux enforce the same... geir On Sep 20, 2006, at 9:36 PM, Leo Li wrote: Hi, all I found that the classlib build fails on windows today. I have tried to fixed it in File main.c 1. move some declarations of variables to the top part of a function. at line 311: char *dirs[2]; at line 1045: int found = 0; int i=0; at line 1067:int strLen 2. comments out unused variable at line 1019: //UDATA newPathLength; -- Leo Li 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] -- Paulex Yang 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]
RE: [drlvm] Trouble Building DRLVM
I checked out everything, and did a clean build, and I'm still running into the same issue. Platform: Gentoo Linux Here is what I see: Running just java: [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...]] [args] ./java: relocation error: /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt.so : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with link time reference it hangs here. Doing java -showversion [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java -showversion Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. java version 1.5.0 pre-alpha : not complete or compatible svn = r448440, (Sep 21 2006), Linux/ia32/gcc 3.4.6, debug build http://incubator.apache.org/harmony it hangs here. Trying to run helloworld: [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java helloworld [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $JAVA_HOME /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/ [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $LD_LIBRARY_PATH /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ Thanks, Armand -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 5:49 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] Trouble Building DRLVM I modified the launcher to include both the vm directory as well as the launcher directory on the PATH/LD_LIBRARY_PATH. Can those that have been having troubles with shared lib loading give it a try, and report back, and please mention the platform you are running on... geir On Sep 20, 2006, at 3:47 PM, Geir Magnusson Jr. wrote: Ok - so to summarize, there are two things here : 1) We need to find a clean way to get bootclasspath.properties. I don't like JAVA_HOME. I'd like to see if we can simply presume a structure, with an override property for people that want to do weird things. 2) We seem to have a simple problem w/ ld.so on our different platforms. I think the simple solution to avoid having to have multiple copies of stuff is to ensure that the directory of the launcher is included in LD_LIBRARY_PATH, which I thought it was. It turns out it isn't, and I'm therefore trying to figure out why it works on my box. geir On Sep 20, 2006, at 11:59 AM, Ivan Volosyuk wrote: I think the whole idea with current behaviour of JAVA_HOME is bad. Launcher should set JAVA_HOME according to it own invocation path. Launcher should override the variable if it set incorrectly. -- Ivan On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote: That appears to be part of the problem Egor, and I've put the initialization into r448241), however, I still get a failure to create the (IBM) VM when JAVA_HOME is pointing at a different JRE. It works ok if home is pointing to the harmony jre or is unset. The failure looks like an init args corruption? Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [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] - 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]
Re: [drlvm] Trouble Building DRLVM
On the 0x1EB day of Apache Harmony Geir Magnusson, Jr. wrote: I modified the launcher to include both the vm directory as well as the launcher directory on the PATH/LD_LIBRARY_PATH. I am not catching .. the launcher directory is known without PATH/LD_LIBRARY_PATH. Why should we look at PATH? Can those that have been having troubles with shared lib loading give it a try, and report back, and please mention the platform you are running on... SUSE 9: * HelloWorld works without complaining, cool! * JAVA_HOME crash is gone, great! (but are we not ignoring JAVA_HOME yet?) * tests: * ThreadTest failed on JET (looks like a known issue:) * ~4 tests failed on OPT (ThreadTest too), I'll look at them * Eclipse (3.2) runs, but reports NPE on startup. Is that a known bug? java.lang.NullPointerException at com.ibm.icu.lang.UCharacter.getProperty(UCharacter.java:6073) at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java:3162) at java.lang.Character.isWhitespace(Character.java:3091) at java.lang.Character.isWhitespace(Character.java:3078) at java.util.Properties.load(Properties.java:378) at java.util.PropertyResourceBundle.init(PropertyResourceBundle.java:44) at java.util.ResourceBundle.handleGetBundle(ResourceBundle.java:286) at java.util.ResourceBundle.handleGetBundle(ResourceBundle.java:308) at java.util.ResourceBundle.handleGetBundle(ResourceBundle.java:308) at java.util.ResourceBundle.getBundle(ResourceBundle.java:132) at org.apache.harmony.luni.util.MsgHelp$1.run(MsgHelp.java:112) at java.security.AccessController.doPrivilegedImpl(Unknown Source) at java.security.AccessController.doPrivileged(Unknown Source) at org.apache.harmony.luni.util.MsgHelp.setLocale(MsgHelp.java:109) at org.apache.harmony.luni.util.Msg.clinit(Msg.java:47) at java.util.zip.ZipFile.openZip(ZipFile.java:116) at java.util.zip.ZipFile.init(ZipFile.java:91) at java.util.jar.JarFile.init(JarFile.java:165) at org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection.openJarFile(JarURLConnection.java:237) at org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection.findJarFile(JarURLConnection.java:176) at org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:143) at org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:159) at java.net.URLClassLoader.findResourceImpl(URLClassLoader.java:714) at java.net.URLClassLoader$5.run(URLClassLoader.java:665) at java.net.URLClassLoader$5.run(URLClassLoader.java:664) at java.security.AccessController.doPrivilegedImpl(Unknown Source) at java.security.AccessController.doPrivileged(Unknown Source) at java.net.URLClassLoader.findResource(URLClassLoader.java:663) at java.lang.ClassLoader$BootstrapLoader.findResource(Unknown Source) at java.lang.ClassLoader.getResource(Unknown Source) at java.lang.ClassLoader.getResourceAsStream(Unknown Source) at java.lang.ClassLoader.getSystemResourceAsStream(Unknown Source) at java.lang.Class.getResourceAsStream(Unknown Source) at com.ibm.icu.impl.ICUData.getStream(ICUData.java:52) at com.ibm.icu.impl.ICUData.getRequiredStream(ICUData.java:97) at com.ibm.icu.impl.UPropertyAliases.init(UPropertyAliases.java:122) at com.ibm.icu.lang.UCharacter.clinit(UCharacter.java:5680) at java.lang.Character.isWhitespace(Character.java:3091) at java.lang.Character.isWhitespace(Character.java:3078) at java.util.Properties.load(Properties.java:378) at org.eclipse.core.launcher.Main.load(Main.java:1475) at org.eclipse.core.launcher.Main.loadProperties(Main.java:1446) at org.eclipse.core.launcher.Main.loadConfiguration(Main.java:1429) at org.eclipse.core.launcher.Main.processConfiguration(Main.java:1243) at org.eclipse.core.launcher.Main.basicRun(Main.java:262) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) geir On Sep 20, 2006, at 3:47 PM, Geir Magnusson Jr. wrote: Ok - so to summarize, there are two things here : 1) We need to find a clean way to get bootclasspath.properties. I don't like JAVA_HOME. I'd like to see if we can simply presume a structure, with an override property for people that want to do weird things. 2) We seem to have a simple problem w/ ld.so on our different platforms. I think the simple solution to avoid having to have multiple copies of stuff is to ensure that the directory of the launcher is included in LD_LIBRARY_PATH, which I thought it was. It turns out it isn't, and I'm therefore trying to
Re: [classlib]build failed on windows
Hi, Paulex: I plan to fix the warning in module luni first if no one objects.:) On 9/21/06, Paulex Yang [EMAIL PROTECTED] wrote: Leo Li wrote: Dear Geir: I advise to use -Werror in Linux compiling but I am not sure of the side-effect. I am now trying to know whether all the warning can be fixed in Linux.:) Volunteer is welcome:). If the errors number is too large to be fixed in one run, I suggest to fix them one module by another. On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Sorry. My fault. Fixing now. I need to find settings to make gcc on linux enforce the same... geir On Sep 20, 2006, at 9:36 PM, Leo Li wrote: Hi, all I found that the classlib build fails on windows today. I have tried to fixed it in File main.c 1. move some declarations of variables to the top part of a function. at line 311: char *dirs[2]; at line 1045: int found = 0; int i=0; at line 1067:int strLen 2. comments out unused variable at line 1019: //UDATA newPathLength; -- Leo Li 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] -- Paulex Yang 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: [classlib][luni] launcher/shared/main.c compile errors on Win32
Heh,
There are modern languages and platforms for goodness. Who cares about
those ancient low-level sundry ;)
2006/9/21, Nathan Beyer [EMAIL PROTECTED]:
Yeah, I thought modern compilers could handle that too, which is part of my
hesitation on applying a fix. Is there some sort of flag that we're missing
to kick this in for MSVC?
As for char *dir[]; - I didn't try that in the declaration, so that might
work.
-Nathan
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 9:07 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] launcher/shared/main.c compile errors on
Win32
Arrrgh.
When I was making those changes I was thinking A long time ago, this
would have been a problem, but thank goodness we're using modern
compilers now...
I guess not. Sorry about that. Teaches me to jump to
conclusions... fixing now
Did it reject char *dirs[];?
geir
On Sep 20, 2006, at 9:30 PM, Nathan Beyer wrote:
I ran into some compile errors in luni's launcher/shared/main.c,
which I
believe were added here [1]. I made some local changes to get it to
compile
and run, but I wanted to pass the diff by the real C experts in the
crowd,
as I'm not much of C hacker.
Based on the compile errors, the problem seemed to be that the local
variables weren't declared at the beginning of the method. I moved
up the
declarations to the top of their respective methods. There was also an
unused variable. Check out the below diff and let me know if it
looks okay
or not.
Thanks.
-Nathan
[1] http://svn.apache.org/viewvc?view=rev
http://svn.apache.org/viewvc?view=revrevision=448355
revision=448355
Index: main.c
===
--- main.c (revision 448406)
+++ main.c (working copy)
@@ -132,6 +132,7 @@
int genericLauncher = 0;
char *str;
char *knownGenericNames[] = { java, java.exe, javaw.exe,
NULL };
+ char *dirs[] = {NULL, NULL};
PORT_ACCESS_FROM_PORT (args-portLibrary);
@@ -308,7 +309,7 @@
strcat (vmiPath, DIR_SEPERATOR_STRING);
strcat (vmiPath, vmdll);
-char *dirs[2];
dirs[0] = newPathToAdd;
dirs[1] = exeName;
@@ -1016,10 +1017,12 @@
char *oldPath = NULL;
char *variableName = NULL;
char *separator = NULL;
- UDATA newPathLength;
char *newPath;
int rc = 0;
char *exeName;
+ int found = 0;
+ int i = 0;
+ int strLen = 0;
PORT_ACCESS_FROM_PORT (portLibrary);
@@ -1041,9 +1044,6 @@
/*
* see if we can find all paths in the current path
*/
-
- int found = 0;
- int i=0;
for (i=0; i count; i++) {
if (newPathToAdd[i] != NULL strstr(oldPath, newPathToAdd
[i]) != 0) {
@@ -1064,7 +1064,7 @@
* short) and then add the old path on the end
*/
- int strLen = strlen(variableName) + strlen(=) + strlen(oldPath);
+ strLen = strlen(variableName) + strlen(=) + strlen(oldPath);
for (i=0; i count; i++) {
if (newPathToAdd[i] != NULL strstr(oldPath, newPathToAdd
[i]) == 0) {
-
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]
-
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][classlib] thread library - let there be one!
I am not very familiar with this section of the code. But if this is in general true, and the classlib dependency on the hythread_XXX api's is small, what Andrey says above makes sense to me. Why not replace them( monitor enter/exit, TLS access etc. ) with the portability layer macrodefs from thrdsup.h and hymutex.h? And just keep the hythread_XXX around seperately for optional usage by any JVM that may wish to and revisit the issue later? That way we know what is the code we are using and needs to be tested, optimized etc. Thanks, Rana On 9/20/06, Weldon Washburn [EMAIL PROTECTED] wrote: All, Is there something missing from the below analysis? I did a grep for hythread_ in all of the classlib directory. There were 1300 hits of which 1200++ where inside the code that implements classlib hythread itself. In other words, 1200++ hits are most likely irrelevant to a VM developer. As far as I can tell, only the following source files containing hythread_xxx APIs are actually used by Harmony Classlib. Is this accurate? C:\t_harmony\classlib\trunk\modules\archive\src\main\native\zip\shared\zipsup.c(116):#define ENTER() hythread_monitor_enter(hythread_global_monitor())C:\t_harmony\classlib\trunk\modules\archive\src\main\native\zip\shared\zipsup.c(117):#define EXIT() hythread_monitor_exit(hythread_global_monitor()) from c:\t_harmony\classlib\trunk\modules\luni\arc\main\port\shared\hynls.c hythread_monitor_enter (nls-monitor); hythread_monitor_exit (nls-monitor); C:\t_harmony\classlib\trunk\modules\luni\src\main\native\vmls\shared\vmls.c(82): hythread_monitor_enter(globalMonitor); C:\t_harmony\classlib\trunk\modules\luni\src\main\native\vmls\shared\vmls.c(103): hythread_monitor_exit(globalMonitor);
Re: [classlib]build failed on windows
Leo Li wrote: Hi, Paulex: I plan to fix the warning in module luni first if no one objects.:) Go ahead for it. On 9/21/06, Paulex Yang [EMAIL PROTECTED] wrote: Leo Li wrote: Dear Geir: I advise to use -Werror in Linux compiling but I am not sure of the side-effect. I am now trying to know whether all the warning can be fixed in Linux.:) Volunteer is welcome:). If the errors number is too large to be fixed in one run, I suggest to fix them one module by another. On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Sorry. My fault. Fixing now. I need to find settings to make gcc on linux enforce the same... geir On Sep 20, 2006, at 9:36 PM, Leo Li wrote: Hi, all I found that the classlib build fails on windows today. I have tried to fixed it in File main.c 1. move some declarations of variables to the top part of a function. at line 311: char *dirs[2]; at line 1045: int found = 0; int i=0; at line 1067:int strLen 2. comments out unused variable at line 1019: //UDATA newPathLength; -- Leo Li 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] -- Paulex Yang 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] -- Paulex Yang 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]
Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?
Hi, all I will volunteer to generate the document and add it to the website. On 9/14/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So - no matter what happens w/ the docs, we do need this in the code... geir Tim Ellison wrote: yep -- that's what I meant. The on-line doc should be generated from the code comments as it is today. Regards, Tim Morozova, Nadezhda wrote: As I got it, the referenced documentation is created from code already, so I don't quite get Geir's comment ;( Anyway, I agree that keeping docs up-to-date is important. Do you think we can ask the community to update comments with the code changes? This way, the docs will never be out-of-sync. And those reading the code will have a better understanding of what it does. Best regards, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, September 14, 2006 5:36 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub? true, but there's no reason why this couldn't be in the code too... geir Tim Ellison wrote: Our VM interface documentation[1] is drifting out of sync with code changes. If anyone has time to refresh it, with help from the dev list, that would be a very valuable task. We should ensure that VM writers understand how to get the harmony class library code working with their VM. [1] amongst others, http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d oc/kernel_doc/html/index.html?view=co Regards, Tim Oliver Deakin wrote: Geir Magnusson Jr. wrote: This came up in another thread. Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on there being a setInterruptAction() method on java.lang.Thread. I certainly think that this kind of thing should be documented, so the question - should we add this to our Thread stub class? Yes we should - I didn't realise initially that this method was being used (since it was private). Now we know it's in use in AbstractInterruptibleChannel, we'd better put some doc in for future kernel writers. Can someone just bring back the original comments and method stub that was there? Regards, Oliver geir - 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] - 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] -- Leo Li China Software Development Lab, IBM
Re: [General]Different SerialVersionID between RI and Harmony
Stepan Mishura 写道: On 9/21/06, Spark Shen wrote: Tony Wu 写道: I had a look at the comparison result on kaffe.org[1] and I'm very glad to see it had fully achieved the 90 percent code coverage in this September :) In the meanwhile, I noticed many differences from RI were SerialVersionID related. I volunteer to fix these problems if no one objects. [1] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_util Hi Tony: Many are coursed by the spec did not give a offical statement about the SerialVersionID. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL PROTECTED] Thanks stepan. And I think you support us to add those SerialVersionID. :-) Best regards -Stepan. But, since the test reveals the SerialVersionID of RI, I think we should follow RI's behavior. I will join you to supply patch for them. 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]
[drlvm] Should the launcher print uncaught exceptions?
Hi All,
I'm almost done with the implementation of Invocation API for DRLVM.
While testing it I ran into a problem when an exception is printed
twice. I created a simple application which just throws an error and
it is not handled by any exception handler:
public class Test {
public static void main(String [] args) {
throw new Error(my);
}
}
In this case the launcher calls env-ExceptionDescribe() before
destroying VM. Then it calls DestroyJavaVM() which identifies
unhanded exception and calls an uncaught exception handler (see
java.lang.Thread.getUncaughtExceptionHandler()) for the current
thread. By default the handler prints the exception one more time.
That's definitely differs from RI where the exception is printed out
only once.
To identify where the problem is I created another simple test and
runs it on RI and DRLVM:
public class Test {
static class MyHandler implements Thread.UncaughtExceptionHandler {
public void uncaughtException(Thread t, Throwable e) {
System.out.println(My Handler Called!!!);
}
}
public static void main(String [] args) {
Thread.currentThread().setUncaughtExceptionHandler(new MyHandler());
throw new Error(my);
}
}
Here is the output:
RI: java.exe Test
My Handler Called!!!
DRLVM: java.exe Test
java/lang/Error : my
at Test.main (Test.java: 12)
My Handler Called!!!
As you can see RI doesn't print exception stack trace at all. But
DRLVM does. To be precise the launcher does. So we need to fix the
launcher.
Note: The behaviour of DRLVM you have may differ from listed above
since all experiments were done on my local workspace with Invocation
API implemented.
-
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] Build problems - missing bfd.h
On the 0x1EB day of Apache Harmony Robin Garner wrote: Trying to build the latest trunk (r448461) on Ubuntu (6.06). Had to hack build.sh because the ant executable isn't in ANT_HOME, and add a URL to download xalan, but now the build fails with a missing bfd.h (full error message below). Any pointers ? I saw it once. Installing binutils (or binutils-dev) helped. cheers, Robin -- build.native.c: [cc] Starting dependency analysis for 10 files. [cc] 10 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 2 total files to be compiled. [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:21:17: error: bfd.h: No such file or directory [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:22:21: error: dis-asm.h: No such file or directory [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:63: error: syntax error before fprintf_ftype [cc] cc1: warnings being treated as errors [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:65: warning: struct disassemble_info declared inside parameter list [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:65: warning: its scope is only this definition or declaration, which is probably not what you want [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:70: error: field bfd_info has incomplete type [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: error: syntax error before bfd_decoder [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: warning: initialization makes integer from pointer without a cast [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: warning: data definition has no type or storage class [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:89: error: syntax error before src [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function disasm_read_memory: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: buffer undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: (Each undeclared identifier is reported only once [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: for each function it appears in.) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: src undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: n undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: At top level: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:103: error: syntax error before memaddr [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function disasm_print_adress_default: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:105: error: info undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:105: error: memaddr undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function disasm_print: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:177: error: bfd_vma undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:177: error: syntax error before apr_uint32_t [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:183: error: syntax error before apr_uint32_t [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function port_disasm_initialize: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:297: error: disassembler_ftype undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:297: error: syntax error before bfd_print_insn_sym [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function port_disassembler_create: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:330: error: bfd_arch_i386 undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:331: error: bfd_mach_i386_i386_intel_syntax undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:339: error: BFD_ENDIAN_LITTLE undeclared (first use in this function) BUILD FAILED /home/robing/harmony/drlvm/build/make/build.xml:404: The following error occurred while executing
Re: [Non-bug difference]? JIRA-1126
[snip] Vladimir Ivanov http://issues.apache.org/jira/secure/ViewProfile.jspa?name=vladimir unit test. Seems, that patch will be system dependent (special handling for Win should be added) [snip] And I agree with Vladimir Ivanov here, on Win-platform, special handling for file system is needed. 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]
Re: [General]Different SerialVersionID between RI and Harmony
On 9/21/06, Spark Shen wrote: Stepan Mishura 写道: On 9/21/06, Spark Shen wrote: Tony Wu 写道: I had a look at the comparison result on kaffe.org[1] and I'm very glad to see it had fully achieved the 90 percent code coverage in this September :) In the meanwhile, I noticed many differences from RI were SerialVersionID related. I volunteer to fix these problems if no one objects. [1] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_util Hi Tony: Many are coursed by the spec did not give a offical statement about the SerialVersionID. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL PROTECTED] Thanks stepan. And I think you support us to add those SerialVersionID. :-) Sure. -Stepan. Best regards -Stepan. But, since the test reveals the SerialVersionID of RI, I think we should follow RI's behavior. I will join you to supply patch for them. Best regards -- Spark Shen China Software Development Lab, IBM
Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))
Looking at ThreadTest failures I see that all 1421-related failures disappear. But there are 3 new failures which I've never seen before. Two of them actually relate to using the launcher problems, but the third one deserves a special investigation. The problem is that Thread.currentThread().isAlive() returns false now. Can anyone comment on this? Thanks, Elena On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'm not paying much attention to the kernel tests these days while we sort out the main problems. I do think that once we sort out the using the launcher problems, and get the patch backlog applied, we really should go after all of these broken tests We also need to refractor the test framework so including/excluding a test doesn't require changing the test source code... geir On Sep 20, 2006, at 7:22 PM, Weldon Washburn wrote: On 9/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: patch applied, JIRA closed Good. I was just about to suggest the very same thing. I applied both of the 1421 patches and a substantial number of tests now run on windows. At this time I see only the below test failures. I commented out gc.LOS test because it still hangs. [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.jet. Please find the detailed resu [junit] Test java.lang.ClassAnnotationsTest FAILED [junit] Test java.lang.ClassAnnotationsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ClassLoaderTest FAILED [junit] Test java.lang.ClassLoaderTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.opt. Please find the detailed resu [junit] Test java.lang.ClassGenericsTest FAILED (timeout) [junit] Test java.lang.ClassGenericsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using interpreter. Please find the detailed resu geir -- Weldon Washburn 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] -- Thanks, Elena
Re: [general][jira] granting ASF license to a team's work (was: Re: [jira] Assigned: (HARMONY-1486) [doc] Keytool user's guide update)
A simple comment on that JIRA saying that Nadya grants permission will suffice. Regards, Tim Stepan Mishura wrote: Hi, I'd like to understand what a rule for granting ASF license to a team's work is. Let's look into the HARMONY-1486 - its description contains the following phrase: This update is the result of cooperative work of Anton Rusanov and Nadya Morozova. So we have one file that was updated by Anton and Nadya. IIUC, Anton as a reporter granted a license to ASF for inclusion ONLY HIS work. And what about Nadya? Should she confirm by commenting the issue that she agree with inclusion HER work?Or there is nothing to care about. Thanks, Stepan. On 9/21/06, Stepan Mishura (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-1486?page=all ] Stepan Mishura reassigned HARMONY-1486: --- Assignee: Stepan Mishura [doc] Keytool user's guide update - Key: HARMONY-1486 URL: http://issues.apache.org/jira/browse/HARMONY-1486 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Anton Rusanov Assigned To: Stepan Mishura Attachments: Keytool_help.html Key changes in the doc: - added options' descriptions, - added some styles to make reading easier, - merged common options and default values to have a comprehensive set of options used with the tool, - checked and corrected writing style. The document differs from the original draft too much to make a diff. So please, replace the file enhanced/classlib/trunk/doc/tools/Keytool/Keytool_help.html with the attached one. This update is the result of cooperative work of Anton Rusanov and Nadya Morozova. -- 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 -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] NPE is thrown when the kernel tests are run on Windows at revision 448448
On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty(UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle.init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- 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]
Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))
On 9/21/06, Elena Semukhina [EMAIL PROTECTED] wrote: Looking at ThreadTest failures I see that all 1421-related failures disappear. But there are 3 new failures which I've never seen before. Two of them actually relate to using the launcher problems, Is it possible to give more details about this or to file new JIRA issue? Thanks, Vladimir. but the third one deserves a special investigation. The problem is that Thread.currentThread().isAlive() returns false now. Can anyone comment on this? Thanks, Elena On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'm not paying much attention to the kernel tests these days while we sort out the main problems. I do think that once we sort out the using the launcher problems, and get the patch backlog applied, we really should go after all of these broken tests We also need to refractor the test framework so including/excluding a test doesn't require changing the test source code... geir On Sep 20, 2006, at 7:22 PM, Weldon Washburn wrote: On 9/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: patch applied, JIRA closed Good. I was just about to suggest the very same thing. I applied both of the 1421 patches and a substantial number of tests now run on windows. At this time I see only the below test failures. I commented out gc.LOS test because it still hangs. [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.jet. Please find the detailed resu [junit] Test java.lang.ClassAnnotationsTest FAILED [junit] Test java.lang.ClassAnnotationsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ClassLoaderTest FAILED [junit] Test java.lang.ClassLoaderTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.opt. Please find the detailed resu [junit] Test java.lang.ClassGenericsTest FAILED (timeout) [junit] Test java.lang.ClassGenericsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using interpreter. Please find the detailed resu geir -- Weldon Washburn 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] -- Thanks, Elena
Re: [drlvm] Should the launcher print uncaught exceptions?
Hi Evgueni,
I wrote a simple launcher [1] that does the following:
1) Calls CreateJavaVM
2) Runs the main method of your Test class below
3) Calls DestroyJavaVM
Note that it does *not* call env-ExceptionDescribe() before destroying
the VM.
I tested this launcher against the RI and J9 and found that no stack
trace or
error details are printed.
So I would say that it is standard behaviour for the VM not to output any
information about uncaught exceptions when shutting down, and that the
launcher
is expected to call ExceptionDescribe() if it wants any details to be
printed.
So from what you have said below, IMHO we need to:
- Change DRLVM to not print stack trace if there is an uncaught
exception at
shutdown.
- If necessary, change the launcher to make sure ExceptionDescribe() is
called
before DestroyJavaVM().
Does that sound right?
Regards,
Oliver
[1]
#include jni.h
main() {
JNIEnv *env;
JavaVM *jvm;
jint result;
jclass cls;
jmethodID mid;
JavaVMInitArgs vmargs;
vmargs.version = 0x00010002;
vmargs.nOptions = 0;
vmargs.ignoreUnrecognized = JNI_TRUE;
result=JNI_CreateJavaVM(jvm, (void**)env, vmargs);
if (result0) {
fprintf(stderr, Cannot create JavaVM\n);
exit(1);
}
cls = (*env)-FindClass(env, TestClass);
if(cls == NULL)
{
printf(ERROR: FindClass failed.\n);
goto destroy;
}
mid = (*env)-GetStaticMethodID(env, cls, main,
([Ljava/lang/String;)V);
if(mid==NULL)
{
printf(ERROR: GetStaticMethodID call failed.\n);
goto destroy;
}
(*env)-CallStaticVoidMethod(env, cls, mid, NULL);
destroy:
(*jvm)-DestroyJavaVM(jvm);
}
Evgueni Brevnov wrote:
Hi All,
I'm almost done with the implementation of Invocation API for DRLVM.
While testing it I ran into a problem when an exception is printed
twice. I created a simple application which just throws an error and
it is not handled by any exception handler:
public class Test {
public static void main(String [] args) {
throw new Error(my);
}
}
In this case the launcher calls env-ExceptionDescribe() before
destroying VM. Then it calls DestroyJavaVM() which identifies
unhanded exception and calls an uncaught exception handler (see
java.lang.Thread.getUncaughtExceptionHandler()) for the current
thread. By default the handler prints the exception one more time.
That's definitely differs from RI where the exception is printed out
only once.
To identify where the problem is I created another simple test and
runs it on RI and DRLVM:
public class Test {
static class MyHandler implements Thread.UncaughtExceptionHandler {
public void uncaughtException(Thread t, Throwable e) {
System.out.println(My Handler Called!!!);
}
}
public static void main(String [] args) {
Thread.currentThread().setUncaughtExceptionHandler(new
MyHandler());
throw new Error(my);
}
}
Here is the output:
RI: java.exe Test
My Handler Called!!!
DRLVM: java.exe Test
java/lang/Error : my
at Test.main (Test.java: 12)
My Handler Called!!!
As you can see RI doesn't print exception stack trace at all. But
DRLVM does. To be precise the launcher does. So we need to fix the
launcher.
Note: The behaviour of DRLVM you have may differ from listed above
since all experiments were done on my local workspace with Invocation
API implemented.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[doc] no progress on patches for the website :(
Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova
Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))
On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Elena Semukhina [EMAIL PROTECTED] wrote: Looking at ThreadTest failures I see that all 1421-related failures disappear. But there are 3 new failures which I've never seen before. Two of them actually relate to using the launcher problems, Is it possible to give more details about this or to file new JIRA issue? These tests reveal that the main thread's name and thread group hierarchy have been changed with the launcher implementation. As Evgueni said that he worked on Invocation API [1], I asked him to run these tests in his environment and they passed. So we should wait until his changes are approved and committed. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL PROTECTED] Thanks, Elena Thanks, Vladimir. but the third one deserves a special investigation. The problem is that Thread.currentThread().isAlive() returns false now. Can anyone comment on this? Thanks, Elena On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'm not paying much attention to the kernel tests these days while we sort out the main problems. I do think that once we sort out the using the launcher problems, and get the patch backlog applied, we really should go after all of these broken tests We also need to refractor the test framework so including/excluding a test doesn't require changing the test source code... geir On Sep 20, 2006, at 7:22 PM, Weldon Washburn wrote: On 9/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: patch applied, JIRA closed Good. I was just about to suggest the very same thing. I applied both of the 1421 patches and a substantial number of tests now run on windows. At this time I see only the below test failures. I commented out gc.LOS test because it still hangs. [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.jet. Please find the detailed resu [junit] Test java.lang.ClassAnnotationsTest FAILED [junit] Test java.lang.ClassAnnotationsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ClassLoaderTest FAILED [junit] Test java.lang.ClassLoaderTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.opt. Please find the detailed resu [junit] Test java.lang.ClassGenericsTest FAILED (timeout) [junit] Test java.lang.ClassGenericsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using interpreter. Please find the detailed resu geir -- Weldon Washburn 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] -- Thanks, Elena -- Thanks, Elena
Re: [doc] no progress on patches for the website :(
Hi Nadya, I'll take a look. Regards, Tim Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [doc] no progress on patches for the website :(
Great to hear that. Please let me know if you need any help. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 3:30 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Hi Nadya, I'll take a look. Regards, Tim Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [Non-bug difference]? JIRA-1126
I'd like to quote RFC 2396 here: The URI syntax does not require that the scheme-specific-part have any general structure or set of semantics which is common among all URI. However, a subset of URI do share a common syntax for representing hierarchical relationships within the namespace. This generic URI syntax consists of a sequence of four main components: scheme://authoritypath?query each of which, except scheme, may be absent from a particular URI. ... We use the term path to refer to both the abs_path and opaque_part constructs, since they are mutually exclusive for any given URI and can be parsed as a single component. So file://C:/1.txt appears to be a valid URI of the following kind: scheme://path, where path is an opaque_part. This means that #1126 is, actually, a bug. Am I correct? On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: [snip] Vladimir Ivanov http://issues.apache.org/jira/secure/ViewProfile.jspa?name=vladimir unit test. Seems, that patch will be system dependent (special handling for Win should be added) [snip] And I agree with Vladimir Ivanov here, on Win-platform, special handling for file system is needed. 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] - 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] array bounds check implementation
Hello, Egor, Isn't that really just faith based? What if you really do have a very large upper bound? upper bounds are not larger than Integer.MAX_VALUE, and any negative value in unsigned arithmetic is larger. I love this hack. Maybe it's worth to comment it and other tricks like this? Seems it's not too obvious :) -- Regards, Anton Luht, 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]
Re: [doc] no progress on patches for the website :(
I need help g I haven't been changing the website since the css updates. I used to be able to preview the site by browsing docs/index.html but that looks awful now in both Firefox and IE (with the current released site). The live site looks fine to me, so is there something I need to do to preview properly? Regards, Tim Morozova, Nadezhda wrote: Great to hear that. Please let me know if you need any help. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 3:30 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Hi Nadya, I'll take a look. Regards, Tim Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still, may be it
would be nice if two different methods are allocated for parkNanos and
parkUntil - passing the extra boolean parameter seems like an
overhead, though very little.
I agree, just create another method rather than passing in a boolean flag.
How are you going to avoid apps calling these public methods? We can do
a security/calling stack check on each method send, but it may be
preferable to make Threads a singleton and check in a getSingleton() call.
Yes, accessor classes were also designed as sigletones those instances
can only be obtained through the AccessorFactory which handles the
security checks.
I wonder if it may make sense to have a single factory for accessor
classes and Threads.
Another solution could be just to keep our own implementation of the
LockSupport in the luni-kernel (there is nothing to share for the
LockSupport with the original j.u.c, it contains almost no code). Is
there a reason why we can not do that?
Probably best to keep our own primitive operations separate in the
o.a.harmony package namespace.
[2]
http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/mo
dules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/Objects.java
I guess the interesting question would be how do we rearrange the
already existing classes in Harmony, e.g. ObjectAccessor [3] and
ArrayAccessor [4] from the o.a.h.misc.accessors package of the
classlib,
Do these need to be rearranged? Why can't we write the suncompat's
Unsafe equivalents in terms of these accessors?
I wouldn't wish we a have multiple classes which are doing the same
things, even if some of them are delegating work to others (e.g.
Objects is written on top of accessors or accessors are rewritten on
top of Objects) - this seems to me just like extra layers/function
calls.
plus the o.a.util.concurrent.Atomics [5] from the DRLVM.
Yep, these need to be moved into the kernel for all VMs to implement.
We can define them in (a new) concurrent-kernel unless there is
consensus that they would be more generally useful, i.e. misc-kernel or
luni-kernel.
If all VM's are supposed to be 1.5+ compliant anyways, why not just
adding to the luni-kernel...
The proposed Objects seems like a combination of the above three.
For example, the following API set from the Objects:
public static long objectFieldOffset(Field field)
public static void putLong(Object object, long fieldOffset, long
newValue) {
public static long getLong(Object object, long fieldOffset)
is just equivalent to the one from the ObjectAccessor:
public final native long getFieldID(Field f);
public final native void setLong(Object o, long fieldID, long value);
public final native long getLong(Object o, long fieldID);
I agree. We should design the set the accessor/atomic methods that make
sense, then express the suncompat version of Unsafe in terms of them.
Andrey: did you check that everything in Objects is covered by existing
accessor/atomics?
Yes, the Objects is a subset of the existing accessors + Atomics combination.
I guess j.u.concurrent won't use the direct read/write to objects,
except for volatile or atomic access?
Having two different interfaces for doing the same can be confusing -
it may not be clear, what is the relationship between fieldID from
the accessors package and fieldOffset from the Objects.
Is there a big advantage to using longs rather than Field's directly?
It looks like the Atomics may have been that way once, the javadoc still
refers to '@parm field' though the signature is now 'long offset' g.
Right, the initial version was containing Field as a parameter because
the intent was to have no dependencies on accessors package (Atomics
might be in the kernel set, but the accessors are currently not).
If we have a task to identify the minimum set of functionality which
is needed for j.u.concurrent, then it looks like the only object API
set we really may need to pick up is the one which is currently
contained in the o.a.util.concurrent.Atomics.
I believe this is what Nathan did already in the Objects spec -- at
least that was my understanding.
I've noticed that Objects have added simple put/getLong operations
which were not in the Atomics, I'm not sure if the j.u.c code really
needs them (I thought it only needs either atomic or volatile access).
If the purpose is to propose some more generic interface for direct
object access, then why just don't move the existing XXXAccessor and
Atomics to the luni-kernel and go with their combination?
Do accessors need to be in kernel? They are implemented solely in terms
of JNI - right?
Right. It is clear that now we have a set of API's that provide
different type of access to objects (e.g. simple, atomic or volatile),
arrays and threads. I can imagine the following types of it's
RE: [doc] no progress on patches for the website :(
Tim, I guess the issue is with the link to site.css that is in harmony/site. I have not been able to devise a nice way to preview either, so I just change the site.vsl file to point to my location of the .css file temporarily. Then I roll back to the original location that works remotely. If you decide to follow my way, go to line 266 in file xdocs/stylesheets/site.vsl and edit the path to site.css link rel=Stylesheet type=text/css href=/harmony/site.css/ To make the link work for all the pages in different subdirectories, specify an absolute path. Remember to regenerate your site to update all docs in /docs subfolder. This does not look like a graceful solution, but I don't know what to else to do. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 4:07 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( I need help g I haven't been changing the website since the css updates. I used to be able to preview the site by browsing docs/index.html but that looks awful now in both Firefox and IE (with the current released site). The live site looks fine to me, so is there something I need to do to preview properly? Regards, Tim Morozova, Nadezhda wrote: Great to hear that. Please let me know if you need any help. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 3:30 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Hi Nadya, I'll take a look. Regards, Tim Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [drlvm] Should the launcher print uncaught exceptions?
Oliver,
Yes, I got the same result on RI when starting VM by your simple
launcher. Assume it is OK not to print an error message and stacke
trace of an unhandled exception in JavaDestroyVM(). How about calling
uncaught exception handler? According to the spec it must be called if
terminating thread has an exception. The test shows that the handler
is not called when VM is created by our launcher. But if VM is
created by RI's launcher then everything works fine and the handler is
executed. This means that RI's launcher somehow deals with it (not VM
itself). It seems for me as a bug in RI. Do you think so?
Evgueni
On 9/21/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Evgueni,
I wrote a simple launcher [1] that does the following:
1) Calls CreateJavaVM
2) Runs the main method of your Test class below
3) Calls DestroyJavaVM
Note that it does *not* call env-ExceptionDescribe() before destroying
the VM.
I tested this launcher against the RI and J9 and found that no stack
trace or
error details are printed.
So I would say that it is standard behaviour for the VM not to output any
information about uncaught exceptions when shutting down, and that the
launcher
is expected to call ExceptionDescribe() if it wants any details to be
printed.
So from what you have said below, IMHO we need to:
- Change DRLVM to not print stack trace if there is an uncaught
exception at
shutdown.
- If necessary, change the launcher to make sure ExceptionDescribe() is
called
before DestroyJavaVM().
Does that sound right?
Regards,
Oliver
[1]
#include jni.h
main() {
JNIEnv *env;
JavaVM *jvm;
jint result;
jclass cls;
jmethodID mid;
JavaVMInitArgs vmargs;
vmargs.version = 0x00010002;
vmargs.nOptions = 0;
vmargs.ignoreUnrecognized = JNI_TRUE;
result=JNI_CreateJavaVM(jvm, (void**)env, vmargs);
if (result0) {
fprintf(stderr, Cannot create JavaVM\n);
exit(1);
}
cls = (*env)-FindClass(env, TestClass);
if(cls == NULL)
{
printf(ERROR: FindClass failed.\n);
goto destroy;
}
mid = (*env)-GetStaticMethodID(env, cls, main,
([Ljava/lang/String;)V);
if(mid==NULL)
{
printf(ERROR: GetStaticMethodID call failed.\n);
goto destroy;
}
(*env)-CallStaticVoidMethod(env, cls, mid, NULL);
destroy:
(*jvm)-DestroyJavaVM(jvm);
}
Evgueni Brevnov wrote:
Hi All,
I'm almost done with the implementation of Invocation API for DRLVM.
While testing it I ran into a problem when an exception is printed
twice. I created a simple application which just throws an error and
it is not handled by any exception handler:
public class Test {
public static void main(String [] args) {
throw new Error(my);
}
}
In this case the launcher calls env-ExceptionDescribe() before
destroying VM. Then it calls DestroyJavaVM() which identifies
unhanded exception and calls an uncaught exception handler (see
java.lang.Thread.getUncaughtExceptionHandler()) for the current
thread. By default the handler prints the exception one more time.
That's definitely differs from RI where the exception is printed out
only once.
To identify where the problem is I created another simple test and
runs it on RI and DRLVM:
public class Test {
static class MyHandler implements Thread.UncaughtExceptionHandler {
public void uncaughtException(Thread t, Throwable e) {
System.out.println(My Handler Called!!!);
}
}
public static void main(String [] args) {
Thread.currentThread().setUncaughtExceptionHandler(new
MyHandler());
throw new Error(my);
}
}
Here is the output:
RI: java.exe Test
My Handler Called!!!
DRLVM: java.exe Test
java/lang/Error : my
at Test.main (Test.java: 12)
My Handler Called!!!
As you can see RI doesn't print exception stack trace at all. But
DRLVM does. To be precise the launcher does. So we need to fix the
launcher.
Note: The behaviour of DRLVM you have may differ from listed above
since all experiments were done on my local workspace with Invocation
API implemented.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
-
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]
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
On 9/21/06, Nathan Beyer [EMAIL PROTECTED] wrote:
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 8:11 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
for java.util.concurrent
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still, may be it
would be nice if two different methods are allocated for parkNanos and
parkUntil - passing the extra boolean parameter seems like an
overhead, though very little.
I agree, just create another method rather than passing in a boolean flag.
This sounds appropriate; I'll make an update to Threads.
How are you going to avoid apps calling these public methods? We can do
a security/calling stack check on each method send, but it may be
preferable to make Threads a singleton and check in a getSingleton() call.
I'll add a factory/singleton method, which can be used then perform any
security checks. Then I presume other Classlib code would invoke this via
PrivilegedAction, correct?
The other option could be just to check that the class loader of the
calling method is the same as the one which was used to load Threads -
this is how it is done in the AccessorFactory. I suspect the
PriviledgedAction block would do eventually the same, but possibly
with some extra expense on creating the PriviledgedAction object.
Another solution could be just to keep our own implementation of the
LockSupport in the luni-kernel (there is nothing to share for the
LockSupport with the original j.u.c, it contains almost no code). Is
there a reason why we can not do that?
Probably best to keep our own primitive operations separate in the
o.a.harmony package namespace.
I agree with Tim, but in addition to that I'd like to not fiddle with the
j.u.c code as much as possible, so as to ensure implementation consistency.
[2]
http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/
mo
dules/luni-
kernel/src/main/java/org/apache/harmony/kernel/vm/Objects.java
I guess the interesting question would be how do we rearrange the
already existing classes in Harmony, e.g. ObjectAccessor [3] and
ArrayAccessor [4] from the o.a.h.misc.accessors package of the
classlib,
Do these need to be rearranged? Why can't we write the suncompat's
Unsafe equivalents in terms of these accessors?
Personally, I'm all for combining all of these down into one set of
interfaces in one module. It's really confusing to have all of these
different Object manipulation interfaces that seem alike, but are used in
different places.
I completely agree with this point of view.
plus the o.a.util.concurrent.Atomics [5] from the DRLVM.
Yep, these need to be moved into the kernel for all VMs to implement.
We can define them in (a new) concurrent-kernel unless there is
consensus that they would be more generally useful, i.e. misc-kernel or
luni-kernel.
The proposed Objects seems like a combination of the above three.
For example, the following API set from the Objects:
public static long objectFieldOffset(Field field)
public static void putLong(Object object, long fieldOffset, long
newValue) {
public static long getLong(Object object, long fieldOffset)
is just equivalent to the one from the ObjectAccessor:
public final native long getFieldID(Field f);
public final native void setLong(Object o, long fieldID, long value);
public final native long getLong(Object o, long fieldID);
I agree. We should design the set the accessor/atomic methods that make
sense, then express the suncompat version of Unsafe in terms of them.
Andrey: did you check that everything in Objects is covered by existing
accessor/atomics?
Objects should cover everything that is in Atomics, but we'll need
additional methods to cover the accessor stuff, but that should be trivial.
I guess j.u.concurrent won't use the direct read/write to objects,
except for volatile or atomic access?
Having two different interfaces for doing the same can be confusing -
it may not be clear, what is the relationship between fieldID from
the accessors package and fieldOffset from the Objects.
Is there a big advantage to using longs rather than Field's directly?
It looks like the Atomics may have been that way once, the javadoc still
refers to '@parm field' though the signature is now 'long offset' g.
I would prefer working with Field objects, but we'll need the long offset
values to implement sun.misc.Unsafe. If you haven't looked at that API,
check it out, it's a little weird [1]. The way you manipulate fields is to
lookup the Field, then look up the offset, then you pass the instance and
field offset into the accessor/mutator methods. It's even more difficult for
arrays. You get the field offset, then you get a base offset and scalar
offset for the array field's type (int[], Object[]), which you then
Re: [doc] no progress on patches for the website :(
No worries. I was traveling the last few days and had this on the top of my list to get to. I hope to grind through this all today. geir On Sep 21, 2006, at 6:37 AM, Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] no progress on patches for the website :(
Ok, thanks for the tip Nadya. I'll take it steady and see how we go. I also had problems reading your diffs on HARMONY-1443. There appears to be other unrelated stuff in there too. I've applied the first part of that issue 'manually' so please check carefully that it was done right. The live site may take a while to be updated. Regards, Tim Morozova, Nadezhda wrote: Tim, I guess the issue is with the link to site.css that is in harmony/site. I have not been able to devise a nice way to preview either, so I just change the site.vsl file to point to my location of the .css file temporarily. Then I roll back to the original location that works remotely. If you decide to follow my way, go to line 266 in file xdocs/stylesheets/site.vsl and edit the path to site.css link rel=Stylesheet type=text/css href=/harmony/site.css/ To make the link work for all the pages in different subdirectories, specify an absolute path. Remember to regenerate your site to update all docs in /docs subfolder. This does not look like a graceful solution, but I don't know what to else to do. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 4:07 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( I need help g I haven't been changing the website since the css updates. I used to be able to preview the site by browsing docs/index.html but that looks awful now in both Firefox and IE (with the current released site). The live site looks fine to me, so is there something I need to do to preview properly? Regards, Tim Morozova, Nadezhda wrote: Great to hear that. Please let me know if you need any help. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 3:30 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Hi Nadya, I'll take a look. Regards, Tim Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] NPE is thrown when the kernel tests are run on Windows at revision 448448
Do you think this is a drlvm issue or a classlib issue? geir On Sep 21, 2006, at 1:07 AM, Vladimir Gorr wrote: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty (UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType (UCharacter.java:2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace (UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java: 3091) [junit] at java.lang.Character.isWhitespace(Character.java: 3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle.init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. Thanks, Vladimir. - 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] Build problems - missing bfd.h
On Sep 21, 2006, at 1:09 AM, Robin Garner wrote: Trying to build the latest trunk (r448461) on Ubuntu (6.06). That's my main build platform. No need to hack anything. Had to hack build.sh because the ant executable isn't in ANT_HOME, That's weird. You shouldn't have to do that. and add a URL to download xalan No need to do that either. The xalan problem means that DRLVM wasn't finding the classlib tree correctly, where the Xalan dep is. By default, DRLVM assumes that classlib and it are arranged on the filesystem as they are in SVN : enhanced/ classlib/ trunk/ drlvm/ trunk/ but if you are using the federated build that is enhanced/trunk, then the relationship is different. The best way is to look at build/drlvm.properties.example, copy to build/drlvm.properties and adjust so it's right. , but now the build fails with a missing bfd.h (full error message below). you need to install binutils for bfd, IIRC. Any pointers ? cheers, Robin -- build.native.c: [cc] Starting dependency analysis for 10 files. [cc] 10 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 2 total files to be compiled. [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:21:17: error: bfd.h: No such file or directory [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:22:21: error: dis-asm.h: No such file or directory [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:63: error: syntax error before ‘fprintf_ftype’ [cc] cc1: warnings being treated as errors [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:65: warning: ‘struct disassemble_info’ declared inside parameter list [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:65: warning: its scope is only this definition or declaration, which is probably not what you want [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:70: error: field ‘bfd_info’ has incomplete type [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:81: error: syntax error before ‘bfd_decoder’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:81: warning: initialization makes integer from pointer without a cast [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:81: warning: data definition has no type or storage class [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:89: error: syntax error before ‘src’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c: In function ‘disasm_read_memory’: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:94: error: ‘buffer’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:94: error: (Each undeclared identifier is reported only once [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:94: error: for each function it appears in.) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:94: error: ‘src’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:94: error: ‘n’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c: At top level: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:103: error: syntax error before ‘memaddr’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c: In function ‘disasm_print_adress_default’: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:105: error: ‘info’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:105: error: ‘memaddr’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c: In function ‘disasm_print’: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:177: error: ‘bfd_vma’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:177: error: syntax error before ‘apr_uint32_t’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:183: error: syntax error before ‘apr_uint32_t’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c: In function ‘port_disasm_initialize’: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:297: error: ‘disassembler_ftype’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c:297: error: syntax error before ‘bfd_print_insn_sym’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/ disasm.c: In
[drlvm][vm] vm_strings.cpp compressing to 8-bit (was question about support for compressed StringBuffers)
All, I took a look at this code. I vote for keeping it. The reason is because Java is string intensive and historically things like string compression make a difference to heap footprint and cache miss performance. It looks like a significant amount of work has already been put in this code. Craig, It would be great if you can work on this code and get it going. I would be happy to work with you to get the mods committed to Harmony svn. From: *Craig Zilles [EMAIL PROTECTED]* ** Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: *Sep 19, 2006 1:24 PM* Subject: *question about support for compressed StringBuffers* Reply | Reply to all | Forward | Print | Add sender to Contacts list | Delete this message | Report phishing | Show original | Message text garbled? I noticed in the file trunk/vm/vmcore/src/util/vm_strings.cpp there is some code to support the storage of strings in arrays of (8b) bytes rather than arrays of (16b) unsigned shorts. In the debugger, I placed breakpoints in this code, and it was never active in my run. Can someone tell me the current status of this code and, if it is active, how I can turn it on? (From inspecting the source, it looked inactive via hardcoding false on whether to compress the strings). I might be interested in working on this code. - Craig - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Reply Forward Invite Craig to Gmail Ivan Volosyukto harmony-dev More options Sep 20 (23 hours ago) This is an old code and it is unused for quite some time. Most likely it is broken. -- Ivan On 9/20/06, Craig Zilles [EMAIL PROTECTED] wrote: I noticed in the file trunk/vm/vmcore/src/util/vm_strings.cpp there is some code to support the storage of strings in arrays of (8b) bytes rather than arrays of (16b) unsigned shorts. In the debugger, I placed breakpoints in this code, and it was never active in my run. Can someone tell me the current status of this code and, if it is active, how I can turn it on? (From inspecting the source, it looked inactive via hardcoding false on whether to compress the strings). I might be interested in working on this code. - Show quoted text - - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Reply Forward Invite Ivan to chat Geir Magnusson Jr.to harmony-dev Hide options Sep 20 (14 hours ago) From: *Geir Magnusson Jr. [EMAIL PROTECTED]* Mailed-By: *incubator.apache.org* Reply-To: * [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: *Sep 20, 2006 4:08 PM* Subject: *Re: question about support for compressed StringBuffers* Reply | Reply to all | Forward | Print | Add sender to Contacts list | Delete this message | Report phishing | Show original | Message text garbled? So do we fix it or scrap it? geir -- Weldon Washburn Intel Middleware Products Division
RE: [doc] no progress on patches for the website :(
Geir, Since Tim is already looking into JIRA 1443, perhaps, we can concentrate on updating the README doc? Do you need my help with updates? You've been writing a lot of useful stuff in various emails. Gathering that in one place might be helpful. Best regards, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 5:33 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( No worries. I was traveling the last few days and had this on the top of my list to get to. I hope to grind through this all today. geir On Sep 21, 2006, at 6:37 AM, Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova - 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]
Re: [doc] no progress on patches for the website :(
Geir Magnusson Jr. wrote: I'm pretty familiar with some of the new docs stuff, so I'm happy to take care of them. Well I've started with HARMONY-1443 so I'll see that one through to completion. You can tackle some of the others. Nadya: I've just applied the TM.html patch, and that refers to a number of images that are missing. Can you send them along too? Regards, Tim On Sep 21, 2006, at 9:25 AM, Tim Ellison wrote: Ok, thanks for the tip Nadya. I'll take it steady and see how we go. I also had problems reading your diffs on HARMONY-1443. There appears to be other unrelated stuff in there too. I've applied the first part of that issue 'manually' so please check carefully that it was done right. The live site may take a while to be updated. Regards, Tim Morozova, Nadezhda wrote: Tim, I guess the issue is with the link to site.css that is in harmony/site. I have not been able to devise a nice way to preview either, so I just change the site.vsl file to point to my location of the .css file temporarily. Then I roll back to the original location that works remotely. If you decide to follow my way, go to line 266 in file xdocs/stylesheets/site.vsl and edit the path to site.css link rel=Stylesheet type=text/css href=/harmony/site.css/ To make the link work for all the pages in different subdirectories, specify an absolute path. Remember to regenerate your site to update all docs in /docs subfolder. This does not look like a graceful solution, but I don't know what to else to do. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 4:07 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( I need help g I haven't been changing the website since the css updates. I used to be able to preview the site by browsing docs/index.html but that looks awful now in both Firefox and IE (with the current released site). The live site looks fine to me, so is there something I need to do to preview properly? Regards, Tim Morozova, Nadezhda wrote: Great to hear that. Please let me know if you need any help. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 3:30 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Hi Nadya, I'll take a look. Regards, Tim Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Sep 21, 2006, at 1:30 AM, Alexey Petrenko wrote: 2006/9/20, Geir Magnusson Jr. [EMAIL PROTECTED]: I still don't think that people should only be notifying the community about indications of interest or such only in the JIRA. Sending mail to the dev list should also be in there. Do we really need that? I'm afraid that dev list will be flooded by the large number of small similar messages like I'll try to prepare a patch to issue #. And most of dev list readers will not be interested in the most of this messages. I don't think that we'll be flooded, and I think that if we are we can change it. I see the mail lists as the primary communication medium of the project. By just encouraging people to comment in the JIRA, you are effectively establishing a parallel communications channel (remember, we've seen conversations happen entirely in JIRA). Conversation among people expressing interest and others that are interested in watching or helping or such will happen easier if there's one place. When people are annotating JIRAs and not mentioning anything to the dev list, I think those conversations won't happen, and we'll be poorer for it. From the other hand a man who is interested in particular issue can easily check the issue state online or even subscribe to receive all the issue changes in JIRA. And people who wants to receive all the notification can subscribe to harmony-commits list. Anyway JIRA can be configured to send all the notifications to dev list if you think that this info will be useful for everybody. I don't think we want all JIRA notifications to go to the dev lists... there was too much noise when we did that. Also, we should as people to name patch files as HARMONY- JIRA#_whatever_.patch It's very helpful. Yes, this is useful. It seems that most of the people are using this name pattern. And adding this pattern to guideline is a good idea. SY, Alexey On Sep 20, 2006, at 2:44 AM, Alexey Petrenko wrote: I've combined all the ideas. And here is the result. === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/trunk 2.5. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.7. If it is an application-oriented issue, check the application. 2.8. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexei Zakharov wrote: Hi Alexey, IMHO it would be nice to explicitly state (for issue reports and/or resolution providers) that patch to classlib code and patch to test should be two separate patches. I personally posted several combined patches in the past. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: Alexey, What was wrong with the initial suggestion of recommending patches be either relative to the classlib/trunk or classlib/trunk/module/module-name? Seems I was not very attentive... Harmony root or module root looks fine. Any other objections or corrections? SY, Alexey I really don't care much *except* that there were two specific types of patches I was trying to avoid as I mentioned when I first suggested this guideline. So I definitely think a guideline of some form would be constructive. Regards, Mark. On 20 September 2006 at 15:48, Alexey Petrenko [EMAIL PROTECTED] wrote: Then we should remove this requirement at all... Since it is possible to have a patches for a few modules at once. Or for a few modules and a doc. 2006/9/20, Mark Hindess [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] om wrote: Not module build.xml but the main build.xml. Anyway since we got a lot of directories except of modules it is better to make a diff from the root. I anticipate that in time we will have people that only check out the module they wish to work on. So I'm happy to see patches relative to a module's build.xml directory. -Mark. 2006/9/20, Oleg Khaschansky [EMAIL PROTECTED]: 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr unk As Mark noted, the directory where the module's build.xml is located is also acceptable. https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr unk/ modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I've combined all the ideas. And here is the result. === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug . If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it . 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/ trun k 2.5. If the patch requires to add, remove or move some files in th e repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.7. If it is an application-oriented issue, check the application . 2.8. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a
Re: [general][jira] granting ASF license to a team's work (was: Re: [jira] Assigned: (HARMONY-1486) [doc] Keytool user's guide update)
yes, that's sufficient, except that if the item is a heavily modified version of the document that was already contributed and available under the apache license, there's no need for any update from Nadya if she hadn't participated directly in those modifications. geir On Sep 21, 2006, at 4:39 AM, Tim Ellison wrote: A simple comment on that JIRA saying that Nadya grants permission will suffice. Regards, Tim Stepan Mishura wrote: Hi, I'd like to understand what a rule for granting ASF license to a team's work is. Let's look into the HARMONY-1486 - its description contains the following phrase: This update is the result of cooperative work of Anton Rusanov and Nadya Morozova. So we have one file that was updated by Anton and Nadya. IIUC, Anton as a reporter granted a license to ASF for inclusion ONLY HIS work. And what about Nadya? Should she confirm by commenting the issue that she agree with inclusion HER work?Or there is nothing to care about. Thanks, Stepan. On 9/21/06, Stepan Mishura (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-1486?page=all ] Stepan Mishura reassigned HARMONY-1486: --- Assignee: Stepan Mishura [doc] Keytool user's guide update - Key: HARMONY-1486 URL: http://issues.apache.org/jira/browse/ HARMONY-1486 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Anton Rusanov Assigned To: Stepan Mishura Attachments: Keytool_help.html Key changes in the doc: - added options' descriptions, - added some styles to make reading easier, - merged common options and default values to have a comprehensive set of options used with the tool, - checked and corrected writing style. The document differs from the original draft too much to make a diff. So please, replace the file enhanced/classlib/trunk/doc/tools/Keytool/Keytool_help.html with the attached one. This update is the result of cooperative work of Anton Rusanov and Nadya Morozova. -- 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 -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey Petrenko wrote: 2006/9/20, Geir Magnusson Jr. [EMAIL PROTECTED]: I still don't think that people should only be notifying the community about indications of interest or such only in the JIRA. Sending mail to the dev list should also be in there. Do we really need that? I'm afraid that dev list will be flooded by the large number of small similar messages like I'll try to prepare a patch to issue #. And most of dev list readers will not be interested in the most of this messages. It's a low overhead to the dev list, and gives us all a sense of where work is progressing. If you see a mail with [classlib][regex] or whatever it may be a flag if you are already in that area. From the other hand a man who is interested in particular issue can easily check the issue state online or even subscribe to receive all the issue changes in JIRA. And people who wants to receive all the notification can subscribe to harmony-commits list. I'd actually like to see the link made the other way too, that is that mail referencing a HARMONY-XXX tag is linked to the JIRA issue comments page. Anyway JIRA can be configured to send all the notifications to dev list if you think that this info will be useful for everybody. It's already sent to the commit list -- that is fine. Regards, Tim Also, we should as people to name patch files as HARMONY- JIRA#_whatever_.patch It's very helpful. Yes, this is useful. It seems that most of the people are using this name pattern. And adding this pattern to guideline is a good idea. SY, Alexey On Sep 20, 2006, at 2:44 AM, Alexey Petrenko wrote: I've combined all the ideas. And here is the result. === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/trunk 2.5. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.7. If it is an application-oriented issue, check the application. 2.8. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue - 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] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use :
Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))
What are the two launcher related failures? On Sep 21, 2006, at 4:21 AM, Elena Semukhina wrote: Looking at ThreadTest failures I see that all 1421-related failures disappear. But there are 3 new failures which I've never seen before. Two of them actually relate to using the launcher problems, but the third one deserves a special investigation. The problem is that Thread.currentThread().isAlive() returns false now. Can anyone comment on this? Thanks, Elena On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'm not paying much attention to the kernel tests these days while we sort out the main problems. I do think that once we sort out the using the launcher problems, and get the patch backlog applied, we really should go after all of these broken tests We also need to refractor the test framework so including/excluding a test doesn't require changing the test source code... geir On Sep 20, 2006, at 7:22 PM, Weldon Washburn wrote: On 9/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: patch applied, JIRA closed Good. I was just about to suggest the very same thing. I applied both of the 1421 patches and a substantial number of tests now run on windows. At this time I see only the below test failures. I commented out gc.LOS test because it still hangs. [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.jet. Please find the detailed resu [junit] Test java.lang.ClassAnnotationsTest FAILED [junit] Test java.lang.ClassAnnotationsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ClassLoaderTest FAILED [junit] Test java.lang.ClassLoaderTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.opt. Please find the detailed resu [junit] Test java.lang.ClassGenericsTest FAILED (timeout) [junit] Test java.lang.ClassGenericsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using interpreter. Please find the detailed resu geir -- Weldon Washburn 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: harmony-dev- [EMAIL PROTECTED] -- Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [doc] no progress on patches for the website :(
Tim, I've just applied the TM.html patch, and that refers to a number of images that are missing. Can you send them along too? There's a separate JIRA issue about missing images [1]. In fact, none of the current longish docs at the site have images. I decided not to supply them with the patch since they are the same as in the original location, already in SVN. For TM specifically, you need the contents of the folder enhanced/drlvm/trunk/vm/thread/doc/images I think I should have mentioned that in the issue, sorry for confusion. [1] http://issues.apache.org/jira/browse/HARMONY-1520 Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 5:41 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Geir Magnusson Jr. wrote: I'm pretty familiar with some of the new docs stuff, so I'm happy to take care of them. Well I've started with HARMONY-1443 so I'll see that one through to completion. You can tackle some of the others. Nadya: I've just applied the TM.html patch, and that refers to a number of images that are missing. Can you send them along too? Regards, Tim On Sep 21, 2006, at 9:25 AM, Tim Ellison wrote: Ok, thanks for the tip Nadya. I'll take it steady and see how we go. I also had problems reading your diffs on HARMONY-1443. There appears to be other unrelated stuff in there too. I've applied the first part of that issue 'manually' so please check carefully that it was done right. The live site may take a while to be updated. Regards, Tim Morozova, Nadezhda wrote: Tim, I guess the issue is with the link to site.css that is in harmony/site. I have not been able to devise a nice way to preview either, so I just change the site.vsl file to point to my location of the .css file temporarily. Then I roll back to the original location that works remotely. If you decide to follow my way, go to line 266 in file xdocs/stylesheets/site.vsl and edit the path to site.css link rel=Stylesheet type=text/css href=/harmony/site.css/ To make the link work for all the pages in different subdirectories, specify an absolute path. Remember to regenerate your site to update all docs in /docs subfolder. This does not look like a graceful solution, but I don't know what to else to do. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 4:07 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( I need help g I haven't been changing the website since the css updates. I used to be able to preview the site by browsing docs/index.html but that looks awful now in both Firefox and IE (with the current released site). The live site looks fine to me, so is there something I need to do to preview properly? Regards, Tim Morozova, Nadezhda wrote: Great to hear that. Please let me know if you need any help. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 3:30 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Hi Nadya, I'll take a look. Regards, Tim Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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,
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2006/9/21, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi Alexey, IMHO it would be nice to explicitly state (for issue reports and/or resolution providers) that patch to classlib code and patch to test should be two separate patches. I personally posted several combined patches in the past. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? There was an opinion that it is good to apply a test patch first and make sure that it fails before the fix. And then make sure that it does not fail any more. Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: Alexey, What was wrong with the initial suggestion of recommending patches be either relative to the classlib/trunk or classlib/trunk/module/module-name? Seems I was not very attentive... Harmony root or module root looks fine. Any other objections or corrections? SY, Alexey I really don't care much *except* that there were two specific types of patches I was trying to avoid as I mentioned when I first suggested this guideline. So I definitely think a guideline of some form would be constructive. Regards, Mark. On 20 September 2006 at 15:48, Alexey Petrenko [EMAIL PROTECTED] wrote: Then we should remove this requirement at all... Since it is possible to have a patches for a few modules at once. Or for a few modules and a doc. 2006/9/20, Mark Hindess [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] om wrote: Not module build.xml but the main build.xml. Anyway since we got a lot of directories except of modules it is better to make a diff from the root. I anticipate that in time we will have people that only check out the module they wish to work on. So I'm happy to see patches relative to a module's build.xml directory. -Mark. 2006/9/20, Oleg Khaschansky [EMAIL PROTECTED]: 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr unk As Mark noted, the directory where the module's build.xml is located is also acceptable. https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr unk/ modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I've combined all the ideas. And here is the result. === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug . If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it . 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/ trun k 2.5. If the patch requires to add, remove or move some files in th e repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.7. If it is an application-oriented issue, check the application . 2.8. Remember to use issue links if
Re: [vmi] passing -X options to VM
go for it. Thanks On Sep 21, 2006, at 2:05 AM, Mikhail Fursov wrote: Checked -Xem:opt/jet/.. - works fine. The old format had a space between -Xem and config name. The new format is reasonable because it's more RI-like, but help message on -X option in DRLVM still contains parameters formatting like: -Xstats mask -Xgc gc options -Xem em options -Xdumpfile file I going to file a JIRA issue about this problem is nobody minds.. On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 20, 2006, at 11:22 AM, Egor Pasko wrote: On the 0x1EA day of Apache Harmony Mikhail Fursov wrote: On Sep 19, 2006, at 11:02 AM, Tim Ellison wrote: Geir Magnusson Jr. wrote: snip I'm going to modify the launcher to pass -help into the VM when it's been named java* so that it behaves like the tools that come with the Sun's, BEA's and IBM's impelmentation. All, What is the default behaviour of the launcher for -X options? I have found that -Xem option is not passed to VM anymore. I propose to pass all of -X options from the launcher to VM. Are there any potential problems in this solution? makes sense! Today we have our workaround like this: -Dem.properties=server_static That's weird. The launcher doesn't care. I thought I've used -Xem as in -Xem:something geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Mikhail Fursov - 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] Trouble Building DRLVM
On Sep 21, 2006, at 2:13 AM, Egor Pasko wrote: On the 0x1EB day of Apache Harmony Geir Magnusson, Jr. wrote: I modified the launcher to include both the vm directory as well as the launcher directory on the PATH/LD_LIBRARY_PATH. I am not catching .. the launcher directory is known without PATH/LD_LIBRARY_PATH. Why should we look at PATH? Oh - for windows, it sets PATH, for linux it sets LD_LIBRARY_PATH. So I was just describing things in general. Can those that have been having troubles with shared lib loading give it a try, and report back, and please mention the platform you are running on... SUSE 9: * HelloWorld works without complaining, cool! * JAVA_HOME crash is gone, great! (but are we not ignoring JAVA_HOME yet?) * tests: * ThreadTest failed on JET (looks like a known issue:) * ~4 tests failed on OPT (ThreadTest too), I'll look at them * Eclipse (3.2) runs, but reports NPE on startup. Is that a known bug? java.lang.NullPointerException at com.ibm.icu.lang.UCharacter.getProperty(UCharacter.java: 6073) at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java: 3162) at java.lang.Character.isWhitespace(Character.java:3091) at java.lang.Character.isWhitespace(Character.java:3078) [SNIP] I think this is a known problem that someone is looking into. Ok - so it seems that for you, the problem has gone away. We still seem to have it on Gentoo for Armand... geir geir On Sep 20, 2006, at 3:47 PM, Geir Magnusson Jr. wrote: Ok - so to summarize, there are two things here : 1) We need to find a clean way to get bootclasspath.properties. I don't like JAVA_HOME. I'd like to see if we can simply presume a structure, with an override property for people that want to do weird things. 2) We seem to have a simple problem w/ ld.so on our different platforms. I think the simple solution to avoid having to have multiple copies of stuff is to ensure that the directory of the launcher is included in LD_LIBRARY_PATH, which I thought it was. It turns out it isn't, and I'm therefore trying to figure out why it works on my box. geir On Sep 20, 2006, at 11:59 AM, Ivan Volosyuk wrote: I think the whole idea with current behaviour of JAVA_HOME is bad. Launcher should set JAVA_HOME according to it own invocation path. Launcher should override the variable if it set incorrectly. -- Ivan On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote: That appears to be part of the problem Egor, and I've put the initialization into r448241), however, I still get a failure to create the (IBM) VM when JAVA_HOME is pointing at a different JRE. It works ok if home is pointing to the harmony jre or is unset. The failure looks like an init args corruption? Regards, Tim --- -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Egor Pasko, Intel Managed Runtime 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
YES PLEASE :) On Sep 21, 2006, at 6:37 AM, Alexei Zakharov wrote: Hi Alexey, IMHO it would be nice to explicitly state (for issue reports and/or resolution providers) that patch to classlib code and patch to test should be two separate patches. I personally posted several combined patches in the past. :) Regards, 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: Alexey, What was wrong with the initial suggestion of recommending patches be either relative to the classlib/trunk or classlib/trunk/module/module-name? Seems I was not very attentive... Harmony root or module root looks fine. Any other objections or corrections? SY, Alexey I really don't care much *except* that there were two specific types of patches I was trying to avoid as I mentioned when I first suggested this guideline. So I definitely think a guideline of some form would be constructive. Regards, Mark. On 20 September 2006 at 15:48, Alexey Petrenko [EMAIL PROTECTED] wrote: Then we should remove this requirement at all... Since it is possible to have a patches for a few modules at once. Or for a few modules and a doc. 2006/9/20, Mark Hindess [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] om wrote: Not module build.xml but the main build.xml. Anyway since we got a lot of directories except of modules it is better to make a diff from the root. I anticipate that in time we will have people that only check out the module they wish to work on. So I'm happy to see patches relative to a module's build.xml directory. -Mark. 2006/9/20, Oleg Khaschansky [EMAIL PROTECTED]: 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/ enhanced/classlib/tr unk As Mark noted, the directory where the module's build.xml is located is also acceptable. https://svn.apache.org/repos/asf/incubator/harmony/ enhanced/classlib/tr unk/ modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I've combined all the ideas. And here is the result. === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug . If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it . 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/ enhanced/classlib/ trun k 2.5. If the patch requires to add, remove or move some files in th e repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.7. If it is an application-oriented issue, check the application . 2.8. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4.
Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))
On Sep 21, 2006, at 6:48 AM, Elena Semukhina wrote: On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Elena Semukhina [EMAIL PROTECTED] wrote: Looking at ThreadTest failures I see that all 1421-related failures disappear. But there are 3 new failures which I've never seen before. Two of them actually relate to using the launcher problems, Is it possible to give more details about this or to file new JIRA issue? These tests reveal that the main thread's name and thread group hierarchy have been changed with the launcher implementation. But that will be the case anytime in general right? You can't assume what is creating and invoking the VM. As Evgueni said that he worked on Invocation API [1], I asked him to run these tests in his environment and they passed. So we should wait until his changes are approved and committed. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200609.mbox/% [EMAIL PROTECTED] Thanks, Elena Thanks, Vladimir. but the third one deserves a special investigation. The problem is that Thread.currentThread().isAlive() returns false now. Can anyone comment on this? Thanks, Elena On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'm not paying much attention to the kernel tests these days while we sort out the main problems. I do think that once we sort out the using the launcher problems, and get the patch backlog applied, we really should go after all of these broken tests We also need to refractor the test framework so including/ excluding a test doesn't require changing the test source code... geir On Sep 20, 2006, at 7:22 PM, Weldon Washburn wrote: On 9/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: patch applied, JIRA closed Good. I was just about to suggest the very same thing. I applied both of the 1421 patches and a substantial number of tests now run on windows. At this time I see only the below test failures. I commented out gc.LOS test because it still hangs. [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.jet. Please find the detailed resu [junit] Test java.lang.ClassAnnotationsTest FAILED [junit] Test java.lang.ClassAnnotationsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ClassLoaderTest FAILED [junit] Test java.lang.ClassLoaderTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.opt. Please find the detailed resu [junit] Test java.lang.ClassGenericsTest FAILED (timeout) [junit] Test java.lang.ClassGenericsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using interpreter. Please find the detailed resu geir -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Thanks, Elena -- Thanks, Elena - 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] array bounds check implementation
On Sep 21, 2006, at 8:01 AM, Anton Luht wrote: Hello, Egor, Isn't that really just faith based? What if you really do have a very large upper bound? upper bounds are not larger than Integer.MAX_VALUE, and any negative value in unsigned arithmetic is larger. I love this hack. Maybe it's worth to comment it and other tricks like this? Seems it's not too obvious :) I agree. As long as you are utterly convinced that this hack won't fail (rather than it be highly unlikely), sure... -- Regards, Anton Luht, 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Sep 21, 2006, at 9:42 AM, Tim Ellison wrote: Alexei Zakharov wrote: Hi Alexey, IMHO it would be nice to explicitly state (for issue reports and/or resolution providers) that patch to classlib code and patch to test should be two separate patches. I personally posted several combined patches in the past. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? I think it makes it cleaner. You can apply the test patch, w/o the code mods, and then run and show the tests fail. THen apply the code patch, show that things get fixed. geir Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: Alexey, What was wrong with the initial suggestion of recommending patches be either relative to the classlib/trunk or classlib/trunk/module/module-name? Seems I was not very attentive... Harmony root or module root looks fine. Any other objections or corrections? SY, Alexey I really don't care much *except* that there were two specific types of patches I was trying to avoid as I mentioned when I first suggested this guideline. So I definitely think a guideline of some form would be constructive. Regards, Mark. On 20 September 2006 at 15:48, Alexey Petrenko [EMAIL PROTECTED] wrote: Then we should remove this requirement at all... Since it is possible to have a patches for a few modules at once. Or for a few modules and a doc. 2006/9/20, Mark Hindess [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] om wrote: Not module build.xml but the main build.xml. Anyway since we got a lot of directories except of modules it is better to make a diff from the root. I anticipate that in time we will have people that only check out the module they wish to work on. So I'm happy to see patches relative to a module's build.xml directory. -Mark. 2006/9/20, Oleg Khaschansky [EMAIL PROTECTED]: 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/tr unk As Mark noted, the directory where the module's build.xml is located is also acceptable. https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/tr unk/ modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I've combined all the ideas. And here is the result. === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug . If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it . 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/ trun k 2.5. If the patch requires to add, remove or move some files in th e repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.7. If it is an application-oriented issue, check the application . 2.8. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the
Re: [doc] no progress on patches for the website :(
This is why I was going to do this. I understood the problem. :) geir On Sep 21, 2006, at 9:47 AM, Morozova, Nadezhda wrote: Tim, I've just applied the TM.html patch, and that refers to a number of images that are missing. Can you send them along too? There's a separate JIRA issue about missing images [1]. In fact, none of the current longish docs at the site have images. I decided not to supply them with the patch since they are the same as in the original location, already in SVN. For TM specifically, you need the contents of the folder enhanced/drlvm/trunk/vm/thread/doc/images I think I should have mentioned that in the issue, sorry for confusion. [1] http://issues.apache.org/jira/browse/HARMONY-1520 Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 5:41 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Geir Magnusson Jr. wrote: I'm pretty familiar with some of the new docs stuff, so I'm happy to take care of them. Well I've started with HARMONY-1443 so I'll see that one through to completion. You can tackle some of the others. Nadya: I've just applied the TM.html patch, and that refers to a number of images that are missing. Can you send them along too? Regards, Tim On Sep 21, 2006, at 9:25 AM, Tim Ellison wrote: Ok, thanks for the tip Nadya. I'll take it steady and see how we go. I also had problems reading your diffs on HARMONY-1443. There appears to be other unrelated stuff in there too. I've applied the first part of that issue 'manually' so please check carefully that it was done right. The live site may take a while to be updated. Regards, Tim Morozova, Nadezhda wrote: Tim, I guess the issue is with the link to site.css that is in harmony/site. I have not been able to devise a nice way to preview either, so I just change the site.vsl file to point to my location of the .css file temporarily. Then I roll back to the original location that works remotely. If you decide to follow my way, go to line 266 in file xdocs/stylesheets/site.vsl and edit the path to site.css link rel=Stylesheet type=text/css href=/harmony/site.css/ To make the link work for all the pages in different subdirectories, specify an absolute path. Remember to regenerate your site to update all docs in /docs subfolder. This does not look like a graceful solution, but I don't know what to else to do. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 4:07 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( I need help g I haven't been changing the website since the css updates. I used to be able to preview the site by browsing docs/index.html but that looks awful now in both Firefox and IE (with the current released site). The live site looks fine to me, so is there something I need to do to preview properly? Regards, Tim Morozova, Nadezhda wrote: Great to hear that. Please let me know if you need any help. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 3:30 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Hi Nadya, I'll take a look. Regards, Tim Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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 :
Re: [drlvm] Should the launcher print uncaught exceptions?
Evgueni Brevnov wrote:
Oliver,
Yes, I got the same result on RI when starting VM by your simple
launcher. Assume it is OK not to print an error message and stacke
trace of an unhandled exception in JavaDestroyVM(). How about calling
uncaught exception handler? According to the spec it must be called if
terminating thread has an exception. The test shows that the handler
is not called when VM is created by our launcher. But if VM is
created by RI's launcher then everything works fine and the handler is
executed. This means that RI's launcher somehow deals with it (not VM
itself). It seems for me as a bug in RI. Do you think so?
Hi Evgueni,
I see the same thing - if I run your second Test class (the
UncaughtExceptionHandler
test) with my simple launcher on the RI and J9 I do not see any output.
i.e. the MyHandler.uncaughtException() method is never called.
Having a Google around I found a link to a Sun bug registered for this [1].
All our launcher needs to do is call DetachCurrentThread() on the main
thread before DestroyJavaVM(), and the UncaughtExceptionHandler will
be called as expected. (This bug only occurs with exception handlers
registered to the main thread - I verified this with [2] which has its
non-main
thread's exception handler called correctly)
So if you add the line:
(*jvm)-DetachCurrentThread(jvm);
to my simple launcher just before the DestroyJavaVM() call, you will see
that the MyHandler.uncaughtException() is called for the main thread, and
the test works as expected.
This looks like it needs to be added to our launcher - do you agree?
What is even more interesting is that if I run your more simple Test class
(the one that just does 'throw new Error(my);'), with the
DetachCurrentThread()
call added to the simple launcher I get a stack trace printed on both RI
and J9!
Again it appears that this is only a problem with the main thread (if
you alter
[2] before so that the handler is not registered, you get the expected
stack trace).
So it seems that adding DetachCurrentThread to the launcher fixes both
problems!
Regards,
Oliver
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4992454
[2]
public class Test {
static class MyHandler implements Thread.UncaughtExceptionHandler {
public void uncaughtException(Thread t, Throwable e) {
System.out.println(My Handler Called!!!);
}
}
static class MyRunnable implements Runnable {
public void run() {
Thread.currentThread().setUncaughtExceptionHandler(new
MyHandler());
throw new Error(my);
}
}
public static void main(String [] args) {
Thread t = new Thread(new MyRunnable());
t.start();
try {
t.join();
} catch (InterruptedException e) {
System.out.println(Interrupted!);
}
}
}
Evgueni
On 9/21/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Evgueni,
I wrote a simple launcher [1] that does the following:
1) Calls CreateJavaVM
2) Runs the main method of your Test class below
3) Calls DestroyJavaVM
Note that it does *not* call env-ExceptionDescribe() before destroying
the VM.
I tested this launcher against the RI and J9 and found that no stack
trace or
error details are printed.
So I would say that it is standard behaviour for the VM not to output
any
information about uncaught exceptions when shutting down, and that the
launcher
is expected to call ExceptionDescribe() if it wants any details to be
printed.
So from what you have said below, IMHO we need to:
- Change DRLVM to not print stack trace if there is an uncaught
exception at
shutdown.
- If necessary, change the launcher to make sure ExceptionDescribe() is
called
before DestroyJavaVM().
Does that sound right?
Regards,
Oliver
[1]
#include jni.h
main() {
JNIEnv *env;
JavaVM *jvm;
jint result;
jclass cls;
jmethodID mid;
JavaVMInitArgs vmargs;
vmargs.version = 0x00010002;
vmargs.nOptions = 0;
vmargs.ignoreUnrecognized = JNI_TRUE;
result=JNI_CreateJavaVM(jvm, (void**)env, vmargs);
if (result0) {
fprintf(stderr, Cannot create JavaVM\n);
exit(1);
}
cls = (*env)-FindClass(env, TestClass);
if(cls == NULL)
{
printf(ERROR: FindClass failed.\n);
goto destroy;
}
mid = (*env)-GetStaticMethodID(env, cls, main,
([Ljava/lang/String;)V);
if(mid==NULL)
{
printf(ERROR: GetStaticMethodID call failed.\n);
goto destroy;
}
(*env)-CallStaticVoidMethod(env, cls, mid, NULL);
destroy:
(*jvm)-DestroyJavaVM(jvm);
}
Evgueni Brevnov wrote:
Hi All,
I'm almost done with the implementation of Invocation API for DRLVM.
While testing it I ran into a problem when an exception is printed
twice. I created a simple application which just throws an error and
it is not handled by any exception handler:
public class Test {
public static void main(String [] args) {
throw new Error(my);
}
}
In this case the launcher calls
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
How does it help to attach them separately? Just to implement the algorithm for committers described earlier by Alexey: 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. ... Regards, 2006/9/21, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi Alexey, IMHO it would be nice to explicitly state (for issue reports and/or resolution providers) that patch to classlib code and patch to test should be two separate patches. I personally posted several combined patches in the past. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: Alexey, What was wrong with the initial suggestion of recommending patches be either relative to the classlib/trunk or classlib/trunk/module/module-name? Seems I was not very attentive... Harmony root or module root looks fine. Any other objections or corrections? SY, Alexey I really don't care much *except* that there were two specific types of patches I was trying to avoid as I mentioned when I first suggested this guideline. So I definitely think a guideline of some form would be constructive. Regards, Mark. On 20 September 2006 at 15:48, Alexey Petrenko [EMAIL PROTECTED] wrote: Then we should remove this requirement at all... Since it is possible to have a patches for a few modules at once. Or for a few modules and a doc. 2006/9/20, Mark Hindess [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] om wrote: Not module build.xml but the main build.xml. Anyway since we got a lot of directories except of modules it is better to make a diff from the root. I anticipate that in time we will have people that only check out the module they wish to work on. So I'm happy to see patches relative to a module's build.xml directory. -Mark. 2006/9/20, Oleg Khaschansky [EMAIL PROTECTED]: 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr unk As Mark noted, the directory where the module's build.xml is located is also acceptable. https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr unk/ modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I've combined all the ideas. And here is the result. === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug . If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it . 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/ trun k 2.5. If the patch requires to add, remove or move some files in th e repository, add the
[drlvm][jit] Internal testing framework for Jitrino.OPT compiler
All, This is the proposal to start the discussion and implementation of Jitrino.OPT compiler internal testing framework. There are a lot of optimizations in Jitrino with a variety of options but only minor part of them is used and tested in the default configuration. The result is when adding new features it's very easy to make a change that conflict with one of the unused modes. Another example is optimization interdependencies. Fixing a bug for a one IR (intermediate compiler representation of user's code) we can turn the optimization off for another IR. Once we have most of such situations encoded as separate reliability tests we can run the check and found all collisions. My vision that the most precise IR optimizations tests should check the IR to prove that optimization really does what it is expected to do. The tests for separate optimizations and functions inside the Jitrino compiler will also require a throughout documentation and understanding of the code. I put the initial implementation of the testing framework code to JIRA and hope that the experience of JIT and QA gurus and volunteers will help us to make this subproject successful. Here is the small description of the testing framework (the way how I understand it). Hope to hear your suggestions here. 1) Every test (set of tests) is executed in a separate JVM instance. The VM instance is run by special adapter that is integrated into a common ant+junit framework. 2) The compilation of the special 'marker' method triggers the compiler to execute a test. The trigger code is placed to the action called test_runner in the sources 3) The test_runner action gets the configuration from the cmd-line parameters or Java properties. 4) The test_runner action selects the test (TestCase) from the test registry (TestRegistry), prepares the environment and runs it. 5) The environment of the test is IR and is called IRTemplate. 6) Once test is passed the test_runner reports PASSED/FAILED+details to output. The output is processed by JVM runner (1) Any comments/volunteers to help me with this task? There are lot of algorithms in JIT have never been tested this way, so the tasks looks very interesting. + See JIRA [ http://issues.apache.org/jira/browse/HARMONY-1531 ] for the sample code. -- Mikhail Fursov
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Weldon, Robin thank you for the comments. There are just a few steps left to do before Jitrino.OPT will have usable unboxed package implementation. Right now I'm working on atomic operations (prepare/attempt pair), and I do not completely understand the semantic of the 'prepare' method. The prepareXYZ method looks like a simple load and is not an atomic operation by itself. Are there any examples that describe these operations in details? I imagine the following situation in user's code: prepareXYZ() do something attempt() Is this code correct? On 9/21/06, Robin Garner [EMAIL PROTECTED] wrote: Weldon Washburn wrote: On 9/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote: I put the update into JIRA. This update still has a lot of bugs, but is significantly more stable then the initial one. My plan is to work on lock prefix support in Jitrino.OPT CG tomorrow, so if somebody is interested to enhance the current implementation there will no conflicts in our work. + There are several issues to discuss that are not clear to me: 1) Do we allow to save magic class into object fields? If yes, GC must be aware about magics and do not enumerate magic fields. Actually, the GC issues are taken care of at a higher level. The developer who is using vmmagics must extend the Uninterruptible class. That's not actually strictly true, there's also the UninterruptiblePragma exception. More generally, the burden is on the programmer to ensure that objects that you hold an Address of don't move while you hold the reference, and these pragmas are one method of doing that. You could also use locks etc (in theory at least). Another issue is that storing an unboxed object from vmmagic into an arbitrary object field has to be thought through very carefully by the developer. Or else there will be stale pointers running around that will cause hard crashes. In any case it is not a JIT responsibility. If the developer puts an object of type vmmagic Address in the heap then later retrieves a stale pointer, disaster will hit. I know because I have done this accidentally. Magic loads and stores also don't trigger read/write barriers, so the programmer needs to manually insert barriers if they would have been called. 4) Why do we need all of these types: Word, Offset, Extent if they are all just platform dependent unsigned integers? I understand that code of garbage collectors already uses these types and we must support them all, but what was the initial reason to introduce all of them? I thought the same thing when I first started working on MMTk port. Now I see there is benefit in the different types because it makes the code easier to read and also allows java type system to catch dumb errors that otherwise would be left to debugging stage. Once upon a time, magic fields were all just ints, and the present variety evolved over time, precisely for this reason. An ObjectReference may seem mysterious to the casual observer (why don't we just use Object ?). This is present so that MMTk can support languages other than Java (Haskell was my original target, and we have done C#), and also so because the object model of the VM that executes MMTk code may not necessarily be the same as the system that MMTk is managing. So an ObjectReference is the 'moral equivalent' of an object. Thats all for today. Will provide an update in a day or two. On 9/18/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/18/06, Mikhail Fursov [EMAIL PROTECTED] wrote: All, I'm working on the implementation of MMTk's org.vmmagic.unboxedorg/vmmagic/unboxed/package-frame.html package functionality in Jitrino.OPT compiler. If you are interested to participate in the development, I propose to discuss all details in this mail thread. The current state: Part of the functionality of vmmagic package is done in the magic1.patch . See JIRA 1489 (http://issues.apache.org/jira/browse/HARMONY-1489) Tasks that are not finished: 1) Support of unsigned types. 2) Support of atomic prepare/attempt operations 3) Testing suit for vmmagic package. 4) EM64T support I hope items 1) and 2) will be finished in a week or even sooner if someone helps. After it's done the item 4) won't be a problem. I think that the problem (at least for me) is item 3): we need a test suite for vmmagic package. I saw several tests in Weldon's drlvm/trunk/vm/MMTk folder, but this is not sufficient to cover the whole vmmagic package. Does anyone know/can_write a reliability test suite for vmmagic we can use in Harmony? A regression test for vmmagic exists. I have been trying to get it donated and posted to MMTk repository. Its been a couple of months and no response. I will find out if it can be donated to Apache. -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division -- Mikhail Fursov
Re: [drlvm][jit] array bounds check implementation
On Sep 21, 2006, at 5:01 AM, Anton Luht wrote: Hello, Egor, Isn't that really just faith based? What if you really do have a very large upper bound? upper bounds are not larger than Integer.MAX_VALUE, and any negative value in unsigned arithmetic is larger. I love this hack. Maybe it's worth to comment it and other tricks like this? Seems it's not too obvious :) Yes please! - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] no progress on patches for the website :(
Geir Magnusson Jr. wrote: This is why I was going to do this. I understood the problem. :) No problem -- we can do a double act. I've checked in the HARMONY-1443 patches at r448575, you can pick things up from there. I'll close that issue to show that much has been done. Regards, Tim On Sep 21, 2006, at 9:47 AM, Morozova, Nadezhda wrote: Tim, I've just applied the TM.html patch, and that refers to a number of images that are missing. Can you send them along too? There's a separate JIRA issue about missing images [1]. In fact, none of the current longish docs at the site have images. I decided not to supply them with the patch since they are the same as in the original location, already in SVN. For TM specifically, you need the contents of the folder enhanced/drlvm/trunk/vm/thread/doc/images I think I should have mentioned that in the issue, sorry for confusion. [1] http://issues.apache.org/jira/browse/HARMONY-1520 Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 5:41 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Geir Magnusson Jr. wrote: I'm pretty familiar with some of the new docs stuff, so I'm happy to take care of them. Well I've started with HARMONY-1443 so I'll see that one through to completion. You can tackle some of the others. Nadya: I've just applied the TM.html patch, and that refers to a number of images that are missing. Can you send them along too? Regards, Tim On Sep 21, 2006, at 9:25 AM, Tim Ellison wrote: Ok, thanks for the tip Nadya. I'll take it steady and see how we go. I also had problems reading your diffs on HARMONY-1443. There appears to be other unrelated stuff in there too. I've applied the first part of that issue 'manually' so please check carefully that it was done right. The live site may take a while to be updated. Regards, Tim Morozova, Nadezhda wrote: Tim, I guess the issue is with the link to site.css that is in harmony/site. I have not been able to devise a nice way to preview either, so I just change the site.vsl file to point to my location of the .css file temporarily. Then I roll back to the original location that works remotely. If you decide to follow my way, go to line 266 in file xdocs/stylesheets/site.vsl and edit the path to site.css link rel=Stylesheet type=text/css href=/harmony/site.css/ To make the link work for all the pages in different subdirectories, specify an absolute path. Remember to regenerate your site to update all docs in /docs subfolder. This does not look like a graceful solution, but I don't know what to else to do. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 4:07 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( I need help g I haven't been changing the website since the css updates. I used to be able to preview the site by browsing docs/index.html but that looks awful now in both Firefox and IE (with the current released site). The live site looks fine to me, so is there something I need to do to preview properly? Regards, Tim Morozova, Nadezhda wrote: Great to hear that. Please let me know if you need any help. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 3:30 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Hi Nadya, I'll take a look. Regards, Tim Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova --Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [vmi] showing help text
Weird - this showed up this morning on my machine. Sorry about delay. On Sep 20, 2006, at 7:39 AM, Tim Ellison wrote: I think we are agreeing, but have (at least) two things muddled up, so let me try and clarify: 1) Users want VM-specific help text when they use the Harmony launcher and run java -help. 2) Users want tool-specific help when they use the tools launcher, e.g. javac -help. Yes - which is the same problem, IMO - users want specific help for whatever program they are running (java, javac, javah, javap) Dealing with them in reverse order... For (2) the tools launcher passes command-line args to the tools code, so javac -help will be translated into something like: java -cp tools.jar o.a.h.tools.javac.Main -help yep It is the tool code itself that gets the help flag and shows help text. Incidentally, this is how the launcher works today (but see footnote below). For case (1) above, the launcher will have to ask the VM to print its help text, based on whichever VM is being invoked. This is a new requirement for Harmony-compatible VMs that will require a change to the VM interface. I'm not saying that is bad, and we can debate how to provide it (i.e. is it a VMI function call or an extension to the JNI_CreateJavaVM functionality, etc.) I guess I don't grok why we need a change to the VM interface. Why not just pass it through as a VM arg like we do now (for DRLVM anyway) in the same way we pass -Xwhatever ? Was there anything I missed? Footnote : I suggest that we extract the tools-based code in the current launcher, and make the tools launcher a simpler program that re-writes the command-line and exec()'s the generic launcher. Putting these two cases into the same source file only confuses things. (yes I know it was me that did thatg) Hm. Interesting idea. I actually don't mind it as is though. geir Regards, Tim Geir Magnusson Jr. wrote: On Sep 19, 2006, at 12:24 PM, Tim Ellison wrote: Geir Magnusson Jr. wrote: On Sep 19, 2006, at 11:02 AM, Tim Ellison wrote: Geir Magnusson Jr. wrote: snip I'm going to modify the launcher to pass -help into the VM when it's been named java* so that it behaves like the tools that come with the Sun's, BEA's and IBM's impelmentation. As I mentioned before, you if you pass -help or - showversion in the creation of the IBM or Sun VM you will get an error, e.g.: C:\temp\sampletest JVMJ9VM007E Command-line option unrecognised: -help Failed to create VM with rc=-6. These command-line flags are handled by the launcher (not the VM). I need to test that for Sun via a launcher, as just doing java - help w/ the sun JRE works as expected - it prints help. Sun's VM (1.5.0_06) does the same thing: C:\temp\sampletest Unrecognized option: -help Failed to create VM with rc=-1. BTW I'm using the test program I posted here, but passing in - help: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200609.mbox/[EMAIL PROTECTED] Why would one even want to launch Sun this way? I mean, I figure the lack of support of our classlibrary would be a bigger obstacle to use than simply not supporting -help Since in Harmony there is not a 1:1 correlation of launcher to VM implementation you will have to either print out generic help in the launcher (bad) or go for an extension to the VM interface to get/print help text. How about passing -help to the VM? I don't grok the downside to this. DRLVM works this way now. that way any localization issues are up to the VM provider. I'm just pointing out that not all VMs will grok that option, so the launcher should not assume they will. Agreed. But our launcher is for Harmony, and there are already a bunch of pre-reqs... We can add a requirement to the VMI that VMs can answer/print their help text, but right now we have no such thing. Existing VMs will fail to initialize (unless you set ignoreUnrecognized, in which case you won't get help text of course). I'm still confused. When you say existing VMs. you mean J9? Because besides DRLVM, there are no others that work w/ the launcher... Having the launcher print out help based on the executable name would be bad - it has to be some thing else. I don't see that we could do that anyway, since the launcher is always java.exe, and different VMs will have different help text. Right. What I mean is some scheme where we base help text on exe name, like javac java javah etc... So to try to drive this to conclusion, I don't get it - what would be wrong with adding supports all options passed through the launcher except vmdir: and vm: to our list of things that a harmony- supporting VM does? geir Regards, Tim I believe that you could write a useful generic implementation of version info since VMs put that into system properties. True - we could solve the version problem that way... geir Regards, Tim IOW, I think that users
[legal] change of copyright notice policy
The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? 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] Should the launcher print uncaught exceptions?
Still, it seems strange that you should have to call DetachCurrentThread
explicitly to get this behavior. I would have expected that
DestroyJavaVM alone would cause the uncaught exception handler to fire.
Not all apps that embed the VM will know to make this work-around.
Regards,
Tim
Oliver Deakin wrote:
Evgueni Brevnov wrote:
Oliver,
Yes, I got the same result on RI when starting VM by your simple
launcher. Assume it is OK not to print an error message and stacke
trace of an unhandled exception in JavaDestroyVM(). How about calling
uncaught exception handler? According to the spec it must be called if
terminating thread has an exception. The test shows that the handler
is not called when VM is created by our launcher. But if VM is
created by RI's launcher then everything works fine and the handler is
executed. This means that RI's launcher somehow deals with it (not VM
itself). It seems for me as a bug in RI. Do you think so?
Hi Evgueni,
I see the same thing - if I run your second Test class (the
UncaughtExceptionHandler
test) with my simple launcher on the RI and J9 I do not see any output.
i.e. the MyHandler.uncaughtException() method is never called.
Having a Google around I found a link to a Sun bug registered for this [1].
All our launcher needs to do is call DetachCurrentThread() on the main
thread before DestroyJavaVM(), and the UncaughtExceptionHandler will
be called as expected. (This bug only occurs with exception handlers
registered to the main thread - I verified this with [2] which has its
non-main
thread's exception handler called correctly)
So if you add the line:
(*jvm)-DetachCurrentThread(jvm);
to my simple launcher just before the DestroyJavaVM() call, you will see
that the MyHandler.uncaughtException() is called for the main thread, and
the test works as expected.
This looks like it needs to be added to our launcher - do you agree?
What is even more interesting is that if I run your more simple Test class
(the one that just does 'throw new Error(my);'), with the
DetachCurrentThread()
call added to the simple launcher I get a stack trace printed on both RI
and J9!
Again it appears that this is only a problem with the main thread (if
you alter
[2] before so that the handler is not registered, you get the expected
stack trace).
So it seems that adding DetachCurrentThread to the launcher fixes both
problems!
Regards,
Oliver
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4992454
[2]
public class Test {
static class MyHandler implements Thread.UncaughtExceptionHandler {
public void uncaughtException(Thread t, Throwable e) {
System.out.println(My Handler Called!!!);
}
}
static class MyRunnable implements Runnable {
public void run() {
Thread.currentThread().setUncaughtExceptionHandler(new
MyHandler());
throw new Error(my);
}
}
public static void main(String [] args) {
Thread t = new Thread(new MyRunnable());
t.start();
try {
t.join();
} catch (InterruptedException e) {
System.out.println(Interrupted!);
}
}
}
Evgueni
On 9/21/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Evgueni,
I wrote a simple launcher [1] that does the following:
1) Calls CreateJavaVM
2) Runs the main method of your Test class below
3) Calls DestroyJavaVM
Note that it does *not* call env-ExceptionDescribe() before destroying
the VM.
I tested this launcher against the RI and J9 and found that no stack
trace or
error details are printed.
So I would say that it is standard behaviour for the VM not to output
any
information about uncaught exceptions when shutting down, and that the
launcher
is expected to call ExceptionDescribe() if it wants any details to be
printed.
So from what you have said below, IMHO we need to:
- Change DRLVM to not print stack trace if there is an uncaught
exception at
shutdown.
- If necessary, change the launcher to make sure ExceptionDescribe() is
called
before DestroyJavaVM().
Does that sound right?
Regards,
Oliver
[1]
#include jni.h
main() {
JNIEnv *env;
JavaVM *jvm;
jint result;
jclass cls;
jmethodID mid;
JavaVMInitArgs vmargs;
vmargs.version = 0x00010002;
vmargs.nOptions = 0;
vmargs.ignoreUnrecognized = JNI_TRUE;
result=JNI_CreateJavaVM(jvm, (void**)env, vmargs);
if (result0) {
fprintf(stderr, Cannot create JavaVM\n);
exit(1);
}
cls = (*env)-FindClass(env, TestClass);
if(cls == NULL)
{
printf(ERROR: FindClass failed.\n);
goto destroy;
}
mid = (*env)-GetStaticMethodID(env, cls, main,
([Ljava/lang/String;)V);
if(mid==NULL)
{
printf(ERROR: GetStaticMethodID call failed.\n);
goto destroy;
}
(*env)-CallStaticVoidMethod(env, cls, mid, NULL);
destroy:
(*jvm)-DestroyJavaVM(jvm);
}
Re: [DRLVM] Build problems - missing bfd.h
Geir Magnusson Jr. wrote: On Sep 21, 2006, at 1:09 AM, Robin Garner wrote: Trying to build the latest trunk (r448461) on Ubuntu (6.06). That's my main build platform. No need to hack anything. Had to hack build.sh because the ant executable isn't in ANT_HOME, That's weird. You shouldn't have to do that. and add a URL to download xalan No need to do that either. The xalan problem means that DRLVM wasn't finding the classlib tree correctly, where the Xalan dep is. By default, DRLVM assumes that classlib and it are arranged on the filesystem as they are in SVN : enhanced/ classlib/ trunk/ drlvm/ trunk/ but if you are using the federated build that is enhanced/trunk, then the relationship is different. The best way is to look at build/drlvm.properties.example, copy to build/drlvm.properties and adjust so it's right. Can you say that one more time please ;-) Seriously, we need to capture that in a technical FAQ. , but now the build fails with a missing bfd.h (full error message below). you need to install binutils for bfd, IIRC. and that... Regards, Tim Any pointers ? cheers, Robin -- build.native.c: [cc] Starting dependency analysis for 10 files. [cc] 10 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 2 total files to be compiled. [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:21:17: error: bfd.h: No such file or directory [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:22:21: error: dis-asm.h: No such file or directory [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:63: error: syntax error before ‘fprintf_ftype’ [cc] cc1: warnings being treated as errors [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:65: warning: ‘struct disassemble_info’ declared inside parameter list [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:65: warning: its scope is only this definition or declaration, which is probably not what you want [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:70: error: field ‘bfd_info’ has incomplete type [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: error: syntax error before ‘bfd_decoder’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: warning: initialization makes integer from pointer without a cast [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: warning: data definition has no type or storage class [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:89: error: syntax error before ‘src’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function ‘disasm_read_memory’: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: ‘buffer’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: (Each undeclared identifier is reported only once [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: for each function it appears in.) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: ‘src’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: ‘n’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: At top level: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:103: error: syntax error before ‘memaddr’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function ‘disasm_print_adress_default’: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:105: error: ‘info’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:105: error: ‘memaddr’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function ‘disasm_print’: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:177: error: ‘bfd_vma’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:177: error: syntax error before ‘apr_uint32_t’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:183: error: syntax error before ‘apr_uint32_t’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function ‘port_disasm_initialize’: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:297: error: ‘disassembler_ftype’ undeclared (first use in this function) [cc]
Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))
Geir Magnusson Jr. wrote: On Sep 21, 2006, at 6:48 AM, Elena Semukhina wrote: On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Elena Semukhina [EMAIL PROTECTED] wrote: Looking at ThreadTest failures I see that all 1421-related failures disappear. But there are 3 new failures which I've never seen before. Two of them actually relate to using the launcher problems, Is it possible to give more details about this or to file new JIRA issue? These tests reveal that the main thread's name and thread group hierarchy have been changed with the launcher implementation. But that will be the case anytime in general right? You can't assume what is creating and invoking the VM. Right, there is an important group of applications that embed the VM -- i.e. use regular JNI calls to create the VM and run Java code. We should not assume that the Harmony launcher can be used to fix things up to work a particular way. I appreciate that we are evolving towards the final version of the drlvm invocation API, so I mention it as a reminder and not a criticism. Regards, Tim As Evgueni said that he worked on Invocation API [1], I asked him to run these tests in his environment and they passed. So we should wait until his changes are approved and committed. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL PROTECTED] Thanks, Elena Thanks, Vladimir. but the third one deserves a special investigation. The problem is that Thread.currentThread().isAlive() returns false now. Can anyone comment on this? Thanks, Elena On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'm not paying much attention to the kernel tests these days while we sort out the main problems. I do think that once we sort out the using the launcher problems, and get the patch backlog applied, we really should go after all of these broken tests We also need to refractor the test framework so including/excluding a test doesn't require changing the test source code... geir On Sep 20, 2006, at 7:22 PM, Weldon Washburn wrote: On 9/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: patch applied, JIRA closed Good. I was just about to suggest the very same thing. I applied both of the 1421 patches and a substantial number of tests now run on windows. At this time I see only the below test failures. I commented out gc.LOS test because it still hangs. [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.jet. Please find the detailed resu [junit] Test java.lang.ClassAnnotationsTest FAILED [junit] Test java.lang.ClassAnnotationsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ClassLoaderTest FAILED [junit] Test java.lang.ClassLoaderTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using jitrino.opt. Please find the detailed resu [junit] Test java.lang.ClassGenericsTest FAILED (timeout) [junit] Test java.lang.ClassGenericsTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadGroupTest FAILED [junit] Test java.lang.ThreadGroupTest FAILED [echo] FAILED on reference JRE [junit] Test java.lang.ThreadTest FAILED [junit] Test java.lang.ThreadTest FAILED [echo] FAILED on reference JRE [echo] Kernel tests FAILED using interpreter. Please find the detailed resu geir -- Weldon Washburn 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] -- Thanks, Elena --Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[doc] Quick Start and FAQ
QuickStart One of the things I was planning to add to our front-page somewhere is the same thing you find when you buy some kind of consumer electronics, like a camera - a quick start page. We need two of them - QuickStart for Harmony Users and Quickstart for Harmony Contributors, which would be how to get and use the snapshot, and how to checkout and build the code, respectively. For the latter, I was going to advocate that people use the enhanced/ trunk approach, as that's a single checkout for them that turns into the maintainable classlib and drlvm trees. I do need to add a target or two to the /trunk/build.xml script to allow them to do the follow- on checkout w/o having it do the build, but that's easy. Does anyone have a problem with me advocating this method? It still the standard classlib and DRLVM trees that a person can svn update, do diffs, create patches, and if a committer, checkin. But it places them in a very clear and useful on-disk relationship with each other, that can then be used for building the snapshot. FAQ This goes w/o saying what we're going to do :) First question will be How do I add a new FAQ entry? with a template for the xdoc. I was thinking that this should be hosted on the wiki, but there's something really nice about the permanence of the main site. Maybe the last entry on the site will be Where are tehre more FAQs? with a pointer to a wiki page, and then if people don't want to do patches to main page, they can enter them there, and we can harvest easily. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[doc] problem w/ css locally?
I'm doing some website work, and things aren't working locally. I can of course build, but when I look at the generated results, it can't find the stylesheet, and the result is, well, awful. Am I doing something wrong? I can fix it by having link rel=Stylesheet type=text/css href=site.css/ but that means that we have site.css everywhere? One of the advantages of our xdoc system is that you can generate and view the site exactly as it will be seen when deployed, so we should try and ensure we keep that property... 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: [doc] no progress on patches for the website :(
On Sep 21, 2006, at 8:15 AM, Morozova, Nadezhda wrote: Tim, I guess the issue is with the link to site.css that is in harmony/ site. I have not been able to devise a nice way to preview either, so I just change the site.vsl file to point to my location of the .css file temporarily. Then I roll back to the original location that works remotely. This will be a problem the first time someone accidentally commits it and publishes it. Maybe the solution now is to remove any path, and we just drop site.css in every source directory If you decide to follow my way, go to line 266 in file xdocs/stylesheets/site.vsl and edit the path to site.css link rel=Stylesheet type=text/css href=/harmony/site.css/ To make the link work for all the pages in different subdirectories, specify an absolute path. Remember to regenerate your site to update all docs in /docs subfolder. This does not look like a graceful solution, but I don't know what to else to do. I'm going to try to just put it in every directory... Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 4:07 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( I need help g I haven't been changing the website since the css updates. I used to be able to preview the site by browsing docs/index.html but that looks awful now in both Firefox and IE (with the current released site). The live site looks fine to me, so is there something I need to do to preview properly? Regards, Tim Morozova, Nadezhda wrote: Great to hear that. Please let me know if you need any help. Best regards, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 3:30 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] no progress on patches for the website :( Hi Nadya, I'll take a look. Regards, Tim Morozova, Nadezhda wrote: Folks, I have been wondering about the patches to the website and documentation: could somebody please take a look and apply them if they're ok? I mean, some patches have new info that can be important; others improve our website and all. Why not just look into them? Thank you very much. Here's a compilation of the issues I've found that have UNRESOLVED status with no comments except the submitter's: http://issues.apache.org/jira/browse/HARMONY-1520 http://issues.apache.org/jira/browse/HARMONY-1520 - new JIRA that reports there are no images in our docs; issue has explicit instructions on where to take the images from and where to place them https://issues.apache.org/jira/browse/HARMONY-1443 - assorted enhancements to individual webpages + migrating classlib docs into the website; 6 patches currently available https://issues.apache.org/jira/browse/HARMONY-1401 - new document about the execution manager https://issues.apache.org/jira/browse/HARMONY-1170 - additions based on discussions over the mailing list Cheers, Nadya Morozova -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] problem w/ css locally?
I see Tim and Nadya discussed this already. I think we want to keep it as error-free as possible... I'm going to try to just copy site.css on deployment - it means we still only maintain one copy, but then offline and online is the same experience. geir On Sep 21, 2006, at 12:19 PM, Geir Magnusson Jr. wrote: I'm doing some website work, and things aren't working locally. I can of course build, but when I look at the generated results, it can't find the stylesheet, and the result is, well, awful. Am I doing something wrong? I can fix it by having link rel=Stylesheet type=text/css href=site.css/ but that means that we have site.css everywhere? One of the advantages of our xdoc system is that you can generate and view the site exactly as it will be seen when deployed, so we should try and ensure we keep that property... geir - 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]
Re: [doc] problem w/ css locally?
On Sep 21, 2006, at 12:34 PM, Tim Ellison wrote: are you practising for the faq :-) ? the hack is to point to a local copy (and remember not to check the hack in). LOL geir Tim Geir Magnusson Jr. wrote: I'm doing some website work, and things aren't working locally. I can of course build, but when I look at the generated results, it can't find the stylesheet, and the result is, well, awful. Am I doing something wrong? I can fix it by having link rel=Stylesheet type=text/css href=site.css/ but that means that we have site.css everywhere? One of the advantages of our xdoc system is that you can generate and view the site exactly as it will be seen when deployed, so we should try and ensure we keep that property... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [doc] problem w/ css locally?
On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I see Tim and Nadya discussed this already. I think we want to keep it as error-free as possible... I'm going to try to just copy site.css on deployment - it means we still only maintain one copy, but then offline and online is the same experience. one approach would be to parameterise the build by adding a local flag. when this flag is set on the command line, the template would used filepath logic when relativising. means changing the velocity template (but i'm guessing that you still remember how to do that ;-) - robert - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [legal] change of copyright notice policy
I've done the similar task for Apache Yoko project some time ago. I removed original IONA copyright notices and replace them with Apache one. I've used simple command line expression based on the knowledge of copyright notice size. I can do the same thing for Harmony but the patch will be big... :) SY, Alexey 2006/9/21, Geir Magnusson Jr. [EMAIL PROTECTED]: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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]
Re: [doc] problem w/ css locally?
that would work, but again, it takes away the simplicity of never having to think about it - what you see locally is what you get when you deploy, which is a really, really good QA benefit. geir On Sep 21, 2006, at 12:44 PM, robert burrell donkin wrote: On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I see Tim and Nadya discussed this already. I think we want to keep it as error-free as possible... I'm going to try to just copy site.css on deployment - it means we still only maintain one copy, but then offline and online is the same experience. one approach would be to parameterise the build by adding a local flag. when this flag is set on the command line, the template would used filepath logic when relativising. means changing the velocity template (but i'm guessing that you still remember how to do that ;-) - robert - 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]
Re: [legal] change of copyright notice policy
Please, don't do a patch. To make this clear, I'm -1 any massive patch for this. I am very +1 any small perl script that solves the problem, that can be applied by anyone. geir On Sep 21, 2006, at 1:05 PM, Alexey Petrenko wrote: I've done the similar task for Apache Yoko project some time ago. I removed original IONA copyright notices and replace them with Apache one. I've used simple command line expression based on the knowledge of copyright notice size. I can do the same thing for Harmony but the patch will be big... :) SY, Alexey 2006/9/21, Geir Magnusson Jr. [EMAIL PROTECTED]: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Alexey A. Petrenko 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] - 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] Should the launcher print uncaught exceptions?
Tim Ellison wrote:
Still, it seems strange that you should have to call DetachCurrentThread
explicitly to get this behavior. I would have expected that
DestroyJavaVM alone would cause the uncaught exception handler to fire.
Not all apps that embed the VM will know to make this work-around.
Yes, that surprised me too. The bug suggests that the launcher is at
fault for calling
ExceptionDescribe() instead of DetachCurrentThread(). However I would have
thought that this was not necessary in the case where an exception
handler has
been registered, and that the handler would be called during
DestroyJavaVM()'s
execution.
Perhaps this is something that could be fixed in DRLVM? So if
DetachCurrentThread() is called, it runs any registered exception
handlers for that
thread as usual. However, if DestroyJavaVM is called, it makes sure that all
exception handlers are run for every thread.
Regards,
Oliver
Regards,
Tim
Oliver Deakin wrote:
Evgueni Brevnov wrote:
Oliver,
Yes, I got the same result on RI when starting VM by your simple
launcher. Assume it is OK not to print an error message and stacke
trace of an unhandled exception in JavaDestroyVM(). How about calling
uncaught exception handler? According to the spec it must be called if
terminating thread has an exception. The test shows that the handler
is not called when VM is created by our launcher. But if VM is
created by RI's launcher then everything works fine and the handler is
executed. This means that RI's launcher somehow deals with it (not VM
itself). It seems for me as a bug in RI. Do you think so?
Hi Evgueni,
I see the same thing - if I run your second Test class (the
UncaughtExceptionHandler
test) with my simple launcher on the RI and J9 I do not see any output.
i.e. the MyHandler.uncaughtException() method is never called.
Having a Google around I found a link to a Sun bug registered for this [1].
All our launcher needs to do is call DetachCurrentThread() on the main
thread before DestroyJavaVM(), and the UncaughtExceptionHandler will
be called as expected. (This bug only occurs with exception handlers
registered to the main thread - I verified this with [2] which has its
non-main
thread's exception handler called correctly)
So if you add the line:
(*jvm)-DetachCurrentThread(jvm);
to my simple launcher just before the DestroyJavaVM() call, you will see
that the MyHandler.uncaughtException() is called for the main thread, and
the test works as expected.
This looks like it needs to be added to our launcher - do you agree?
What is even more interesting is that if I run your more simple Test class
(the one that just does 'throw new Error(my);'), with the
DetachCurrentThread()
call added to the simple launcher I get a stack trace printed on both RI
and J9!
Again it appears that this is only a problem with the main thread (if
you alter
[2] before so that the handler is not registered, you get the expected
stack trace).
So it seems that adding DetachCurrentThread to the launcher fixes both
problems!
Regards,
Oliver
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4992454
[2]
public class Test {
static class MyHandler implements Thread.UncaughtExceptionHandler {
public void uncaughtException(Thread t, Throwable e) {
System.out.println(My Handler Called!!!);
}
}
static class MyRunnable implements Runnable {
public void run() {
Thread.currentThread().setUncaughtExceptionHandler(new
MyHandler());
throw new Error(my);
}
}
public static void main(String [] args) {
Thread t = new Thread(new MyRunnable());
t.start();
try {
t.join();
} catch (InterruptedException e) {
System.out.println(Interrupted!);
}
}
}
Evgueni
On 9/21/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Evgueni,
I wrote a simple launcher [1] that does the following:
1) Calls CreateJavaVM
2) Runs the main method of your Test class below
3) Calls DestroyJavaVM
Note that it does *not* call env-ExceptionDescribe() before destroying
the VM.
I tested this launcher against the RI and J9 and found that no stack
trace or
error details are printed.
So I would say that it is standard behaviour for the VM not to output
any
information about uncaught exceptions when shutting down, and that the
launcher
is expected to call ExceptionDescribe() if it wants any details to be
printed.
So from what you have said below, IMHO we need to:
- Change DRLVM to not print stack trace if there is an uncaught
exception at
shutdown.
- If necessary, change the launcher to make sure ExceptionDescribe() is
called
before DestroyJavaVM().
Does that sound right?
Regards,
Oliver
[1]
#include jni.h
main() {
JNIEnv *env;
JavaVM *jvm;
jint result;
jclass cls;
jmethodID mid;
JavaVMInitArgs vmargs;
vmargs.version = 0x00010002;
vmargs.nOptions = 0;
vmargs.ignoreUnrecognized = JNI_TRUE;
Re: [legal] change of copyright notice policy
I'll find a bash script which I used for Yoko. If you are OK with bash script :) 2006/9/21, Geir Magnusson Jr. [EMAIL PROTECTED]: Please, don't do a patch. To make this clear, I'm -1 any massive patch for this. I am very +1 any small perl script that solves the problem, that can be applied by anyone. geir On Sep 21, 2006, at 1:05 PM, Alexey Petrenko wrote: I've done the similar task for Apache Yoko project some time ago. I removed original IONA copyright notices and replace them with Apache one. I've used simple command line expression based on the knowledge of copyright notice size. I can do the same thing for Harmony but the patch will be big... :) SY, Alexey 2006/9/21, Geir Magnusson Jr. [EMAIL PROTECTED]: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Alexey A. Petrenko 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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]
Re: [doc] problem w/ css locally?
On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: that would work, but again, it takes away the simplicity of never having to think about it - what you see locally is what you get when you deploy, which is a really, really good QA benefit. the other problem with relativised urls is that local links don't work. this makes it difficult to test links locally. using the absolute URL for the style works except when you want to edit the style sheet. i've been trying to find a good solution to relatized URLs for a while. having a switch means there's a risk of committing the local only files. what would be good is a browser where it's possible to set the base URL for local files. anyone know one? - robert - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] problem w/ css locally?
On Sep 21, 2006, at 1:42 PM, robert burrell donkin wrote: On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: that would work, but again, it takes away the simplicity of never having to think about it - what you see locally is what you get when you deploy, which is a really, really good QA benefit. the other problem with relativised urls is that local links don't work. this makes it difficult to test links locally. Right - up to now, our site was completely testable locally. That's the major benefit of using this system. using the absolute URL for the style works except when you want to edit the style sheet. i've been trying to find a good solution to relatized URLs for a while. having a switch means there's a risk of committing the local only files. yep what would be good is a browser where it's possible to set the base URL for local files. anyone know one? There's no reason to worry about this here. if we just use a site.css in each directory, I think we're ok. geir - robert - 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]
Re: [legal] change of copyright notice policy
I suggest that committers volunteer to run the script (and verify the results etc.) on a module-by-module, rather than package-by-package, basis; plus the VMs of course. Let's list the units of work on the wiki and have people sign-up to convert them. I assume that we will convert *all* copyright blocks in SVN (tools, website, etc.), not just those that would make it into a release, right? What a drag. Tim Geir Magnusson Jr. wrote: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [legal] change of copyright notice policy
Geir Magnusson Jr. wrote: Please, don't do a patch. To make this clear, I'm -1 any massive patch for this. I am very +1 any small perl script that solves the problem, that can be applied by anyone. Is the perl script referenced in the policy doc no good? Regards, Tim On Sep 21, 2006, at 1:05 PM, Alexey Petrenko wrote: I've done the similar task for Apache Yoko project some time ago. I removed original IONA copyright notices and replace them with Apache one. I've used simple command line expression based on the knowledge of copyright notice size. I can do the same thing for Harmony but the patch will be big... :) SY, Alexey 2006/9/21, Geir Magnusson Jr. [EMAIL PROTECTED]: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --Alexey A. Petrenko 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[general] tasks for new snapshot?
Sounds like the launcher issues have been resolved, and we are at least no worse off with handling JAVA_HOME than before. Is it just the HARMONY-1500 Character problem now that would prevent us from cutting a snapshot of code? Anything else I missed? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Quick Start and FAQ
What does: allow them to do the follow-on checkout w/o having it do the build mean? Regards, Tim Geir Magnusson Jr. wrote: QuickStart One of the things I was planning to add to our front-page somewhere is the same thing you find when you buy some kind of consumer electronics, like a camera - a quick start page. We need two of them - QuickStart for Harmony Users and Quickstart for Harmony Contributors, which would be how to get and use the snapshot, and how to checkout and build the code, respectively. For the latter, I was going to advocate that people use the enhanced/trunk approach, as that's a single checkout for them that turns into the maintainable classlib and drlvm trees. I do need to add a target or two to the /trunk/build.xml script to allow them to do the follow-on checkout w/o having it do the build, but that's easy. Does anyone have a problem with me advocating this method? It still the standard classlib and DRLVM trees that a person can svn update, do diffs, create patches, and if a committer, checkin. But it places them in a very clear and useful on-disk relationship with each other, that can then be used for building the snapshot. FAQ This goes w/o saying what we're going to do :) First question will be How do I add a new FAQ entry? with a template for the xdoc. I was thinking that this should be hosted on the wiki, but there's something really nice about the permanence of the main site. Maybe the last entry on the site will be Where are tehre more FAQs? with a pointer to a wiki page, and then if people don't want to do patches to main page, they can enter them there, and we can harvest easily. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexei Zakharov wrote: How does it help to attach them separately? Just to implement the algorithm for committers described earlier by Alexey: 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. ... Pah, get yourself a decent patch tool and apply it selectively ;-) Seriously though, I don't care if the test and fix are separate or combined. Regards, Tim 2006/9/21, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi Alexey, IMHO it would be nice to explicitly state (for issue reports and/or resolution providers) that patch to classlib code and patch to test should be two separate patches. I personally posted several combined patches in the past. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: Alexey, What was wrong with the initial suggestion of recommending patches be either relative to the classlib/trunk or classlib/trunk/module/module-name? Seems I was not very attentive... Harmony root or module root looks fine. Any other objections or corrections? SY, Alexey I really don't care much *except* that there were two specific types of patches I was trying to avoid as I mentioned when I first suggested this guideline. So I definitely think a guideline of some form would be constructive. Regards, Mark. On 20 September 2006 at 15:48, Alexey Petrenko [EMAIL PROTECTED] wrote: Then we should remove this requirement at all... Since it is possible to have a patches for a few modules at once. Or for a few modules and a doc. 2006/9/20, Mark Hindess [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] om wrote: Not module build.xml but the main build.xml. Anyway since we got a lot of directories except of modules it is better to make a diff from the root. I anticipate that in time we will have people that only check out the module they wish to work on. So I'm happy to see patches relative to a module's build.xml directory. -Mark. 2006/9/20, Oleg Khaschansky [EMAIL PROTECTED]: 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr unk As Mark noted, the directory where the module's build.xml is located is also acceptable. https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr unk/ modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I've combined all the ideas. And here is the result. === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug . If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it . 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment.
Re: [legal] change of copyright notice policy
On Sep 21, 2006, at 3:04 PM, Tim Ellison wrote: I suggest that committers volunteer to run the script (and verify the results etc.) on a module-by-module, rather than package-by-package, basis; plus the VMs of course. Yes, exactly. I didn't really mean on a package basis. If we get a script soon, I'll just do the VM this week. Let's list the units of work on the wiki and have people sign-up to convert them. I assume that we will convert *all* copyright blocks in SVN (tools, website, etc.), not just those that would make it into a release, right? Yes. What a drag. It really should be no big deal if we just do it lazily for now... Tim Geir Magnusson Jr. wrote: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [legal] change of copyright notice policy
On Sep 21, 2006, at 3:05 PM, Tim Ellison wrote: Geir Magnusson Jr. wrote: Please, don't do a patch. To make this clear, I'm -1 any massive patch for this. I am very +1 any small perl script that solves the problem, that can be applied by anyone. Is the perl script referenced in the policy doc no good? That would work :) Regards, Tim On Sep 21, 2006, at 1:05 PM, Alexey Petrenko wrote: I've done the similar task for Apache Yoko project some time ago. I removed original IONA copyright notices and replace them with Apache one. I've used simple command line expression based on the knowledge of copyright notice size. I can do the same thing for Harmony but the patch will be big... :) SY, Alexey 2006/9/21, Geir Magnusson Jr. [EMAIL PROTECTED]: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir --- -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] --Alexey A. Petrenko 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: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [general] tasks for new snapshot?
On Sep 21, 2006, at 3:08 PM, Tim Ellison wrote: Sounds like the launcher issues have been resolved, and we are at least no worse off with handling JAVA_HOME than before. Is it just the HARMONY-1500 Character problem now that would prevent us from cutting a snapshot of code? Anything else I missed? I've been waiting to be sure the launcher issue is gone before I was going to spin one... geir Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [doc] Quick Start and FAQ
On Sep 21, 2006, at 3:12 PM, Tim Ellison wrote: What does: allow them to do the follow-on checkout w/o having it do the build mean? When you checkout enhanced/trunk, you get a 'working_classlib' directory, and a 'working_vm' directory that, when you fire off ant, will be set to be a working tree for both, respectively. Right now, firing off ant will build the snapshots. But to make it easy, I'll make a $ ant update_dirs or something that does that step to SVN head w/o the follow on building and snapshot making. make sense? geir Regards, Tim Geir Magnusson Jr. wrote: QuickStart One of the things I was planning to add to our front-page somewhere is the same thing you find when you buy some kind of consumer electronics, like a camera - a quick start page. We need two of them - QuickStart for Harmony Users and Quickstart for Harmony Contributors, which would be how to get and use the snapshot, and how to checkout and build the code, respectively. For the latter, I was going to advocate that people use the enhanced/trunk approach, as that's a single checkout for them that turns into the maintainable classlib and drlvm trees. I do need to add a target or two to the /trunk/build.xml script to allow them to do the follow-on checkout w/o having it do the build, but that's easy. Does anyone have a problem with me advocating this method? It still the standard classlib and DRLVM trees that a person can svn update, do diffs, create patches, and if a committer, checkin. But it places them in a very clear and useful on-disk relationship with each other, that can then be used for building the snapshot. FAQ This goes w/o saying what we're going to do :) First question will be How do I add a new FAQ entry? with a template for the xdoc. I was thinking that this should be hosted on the wiki, but there's something really nice about the permanence of the main site. Maybe the last entry on the site will be Where are tehre more FAQs? with a pointer to a wiki page, and then if people don't want to do patches to main page, they can enter them there, and we can harvest easily. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Sep 21, 2006, at 3:27 PM, Tim Ellison wrote: Alexei Zakharov wrote: How does it help to attach them separately? Just to implement the algorithm for committers described earlier by Alexey: 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. ... Pah, get yourself a decent patch tool and apply it selectively ;-) Seriously though, I don't care if the test and fix are separate or combined. I do. what tool do you suggest? Regards, Tim 2006/9/21, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi Alexey, IMHO it would be nice to explicitly state (for issue reports and/or resolution providers) that patch to classlib code and patch to test should be two separate patches. I personally posted several combined patches in the past. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? Regards, Tim 2006/9/20, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/20, Mark Hindess [EMAIL PROTECTED]: Alexey, What was wrong with the initial suggestion of recommending patches be either relative to the classlib/trunk or classlib/trunk/module/module-name? Seems I was not very attentive... Harmony root or module root looks fine. Any other objections or corrections? SY, Alexey I really don't care much *except* that there were two specific types of patches I was trying to avoid as I mentioned when I first suggested this guideline. So I definitely think a guideline of some form would be constructive. Regards, Mark. On 20 September 2006 at 15:48, Alexey Petrenko [EMAIL PROTECTED] wrote: Then we should remove this requirement at all... Since it is possible to have a patches for a few modules at once. Or for a few modules and a doc. 2006/9/20, Mark Hindess [EMAIL PROTECTED]: On 20 September 2006 at 13:56, Alexey Petrenko [EMAIL PROTECTED] om wrote: Not module build.xml but the main build.xml. Anyway since we got a lot of directories except of modules it is better to make a diff from the root. I anticipate that in time we will have people that only check out the module they wish to work on. So I'm happy to see patches relative to a module's build.xml directory. -Mark. 2006/9/20, Oleg Khaschansky [EMAIL PROTECTED]: 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/tr unk As Mark noted, the directory where the module's build.xml is located is also acceptable. https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/tr unk/ modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I've combined all the ideas. And here is the result. === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug . If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it . 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/ trun k 2.5. If the patch requires to add, remove or move some files in th e repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.7. If it is an application-oriented issue, check the application . 2.8. Remember
[drlvm] getting activeMQ to run
Even though we have the jar issue fixed w/t he launcher-based build, I still can't run ActiveMQ using release build on Ubuntu. Can anyone else report success? Or a patch? :) 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: [general] tasks for new snapshot?
we should probably just fix that Character problem and then create a new HDK snapshot. We're not there for JRE yet, but no reason to hold back HDK. geir On Sep 21, 2006, at 3:08 PM, Tim Ellison wrote: Sounds like the launcher issues have been resolved, and we are at least no worse off with handling JAVA_HOME than before. Is it just the HARMONY-1500 Character problem now that would prevent us from cutting a snapshot of code? Anything else I missed? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
On 9/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, Robin thank you for the comments. There are just a few steps left to do before Jitrino.OPT will have usable unboxed package implementation. Right now I'm working on atomic operations (prepare/attempt pair), and I do not completely understand the semantic of the 'prepare' method. The prepareXYZ method looks like a simple load and is not an atomic operation by itself. Are there any examples that describe these operations in details? Robin will correct me if I am wrong. I think the idea is that this is a generic API intended to be used for accessing compare and swap facilities on a bunch of different hardware. And the actual hardware has different memory models, different CAS semantics, etc. Basically the generic facility needed is to first read the CAS target memory location (this is the prepare). If the memory is sitting at a specific value (this is the do something), then do an attempt as follows: old_contents = CAS(expected_specfic_value_that_I_just_read, some_new_value, target_memory_location) If the old_contents are identical to expected_specific_value_that_I_just_read, we know that the CAS succeeded. In other words, you won the competition. Otherwise you lost. I imagine the following situation in user's code: prepareXYZ() do something attempt() Is this code correct? On 9/21/06, Robin Garner [EMAIL PROTECTED] wrote: Weldon Washburn wrote: On 9/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote: I put the update into JIRA. This update still has a lot of bugs, but is significantly more stable then the initial one. My plan is to work on lock prefix support in Jitrino.OPTCG tomorrow, so if somebody is interested to enhance the current implementation there will no conflicts in our work. + There are several issues to discuss that are not clear to me: 1) Do we allow to save magic class into object fields? If yes, GC must be aware about magics and do not enumerate magic fields. Actually, the GC issues are taken care of at a higher level. The developer who is using vmmagics must extend the Uninterruptible class. That's not actually strictly true, there's also the UninterruptiblePragma exception. More generally, the burden is on the programmer to ensure that objects that you hold an Address of don't move while you hold the reference, and these pragmas are one method of doing that. You could also use locks etc (in theory at least). Another issue is that storing an unboxed object from vmmagic into an arbitrary object field has to be thought through very carefully by the developer. Or else there will be stale pointers running around that will cause hard crashes. In any case it is not a JIT responsibility. If the developer puts an object of type vmmagic Address in the heap then later retrieves a stale pointer, disaster will hit. I know because I have done this accidentally. Magic loads and stores also don't trigger read/write barriers, so the programmer needs to manually insert barriers if they would have been called. 4) Why do we need all of these types: Word, Offset, Extent if they are all just platform dependent unsigned integers? I understand that code of garbage collectors already uses these types and we must support them all, but what was the initial reason to introduce all of them? I thought the same thing when I first started working on MMTk port. Now I see there is benefit in the different types because it makes the code easier to read and also allows java type system to catch dumb errors that otherwise would be left to debugging stage. Once upon a time, magic fields were all just ints, and the present variety evolved over time, precisely for this reason. An ObjectReference may seem mysterious to the casual observer (why don't we just use Object ?). This is present so that MMTk can support languages other than Java (Haskell was my original target, and we have done C#), and also so because the object model of the VM that executes MMTk code may not necessarily be the same as the system that MMTk is managing. So an ObjectReference is the 'moral equivalent' of an object. Thats all for today. Will provide an update in a day or two. On 9/18/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/18/06, Mikhail Fursov [EMAIL PROTECTED] wrote: All, I'm working on the implementation of MMTk's org.vmmagic.unboxedorg/vmmagic/unboxed/package-frame.html package functionality in Jitrino.OPT compiler. If you are interested to participate in the development, I propose to discuss all details in this mail thread. The current state: Part of the functionality of vmmagic package is done in the magic1.patch . See JIRA 1489 (http://issues.apache.org/jira/browse/HARMONY-1489) Tasks that are not finished: 1) Support of unsigned types. 2) Support of atomic
Re: [classlib][html] Differences with RI
Hi, I fllled several JIRA issues more than three weeks ago, but they are still unassigned. (HARMONY-1272, 1349, 1350, 1395). We are working in the parser, and there are some issues that should be solved, such as the structure of ContentModel. I would like to hear other people thoughts about this, particularly those from the developers of the existing javax.swing.text.html.parser code Regards Miguel Montes On 8/23/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I think that filing JIRA issue is right way :) 2006/8/23, Miguel Montes [EMAIL PROTECTED]: Hi: We have found several differences between Harmony's implementation of j.s.t.h.parser and the RI. I'm not sure if these should be reported individually as JIRA issues, or should be discussed here. For instance, in j.s.t.h.p.Entity, the RI. encodes isParameter and isGeneral in the type, which is a public field, while the current implementation in Harmony uses two boolean fields. So, the value of a public field is different in both implementations. Another case: ContentModel: The method first() should return the element that must be the first element to appear in a ContentModel. If it's not unique, the RI returns null. For instance, for the following ContentModel: TITLE ISINDEX? BASE? Any of those elements could appear at the beggining of a valid matching expression. So, the method first should return null, because there is not a single element that could be considered as the unique one that can appear at the head of a matching expression. Nevertheless, for this example (as for some others), HARMONY-948 returned a value. For this example, a BASE value was obtained. There are several more. Should we post them as separate JIRA issues, o as one big issue, with the suggeste patches? -- Miguel Montes -- Alexey A. Petrenko 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] -- Miguel Montes
Re: [doc] Quick Start and FAQ
Got it -- thanks. Tim Geir Magnusson Jr. wrote: On Sep 21, 2006, at 3:12 PM, Tim Ellison wrote: What does: allow them to do the follow-on checkout w/o having it do the build mean? When you checkout enhanced/trunk, you get a 'working_classlib' directory, and a 'working_vm' directory that, when you fire off ant, will be set to be a working tree for both, respectively. Right now, firing off ant will build the snapshots. But to make it easy, I'll make a $ ant update_dirs or something that does that step to SVN head w/o the follow on building and snapshot making. make sense? geir Regards, Tim Geir Magnusson Jr. wrote: QuickStart One of the things I was planning to add to our front-page somewhere is the same thing you find when you buy some kind of consumer electronics, like a camera - a quick start page. We need two of them - QuickStart for Harmony Users and Quickstart for Harmony Contributors, which would be how to get and use the snapshot, and how to checkout and build the code, respectively. For the latter, I was going to advocate that people use the enhanced/trunk approach, as that's a single checkout for them that turns into the maintainable classlib and drlvm trees. I do need to add a target or two to the /trunk/build.xml script to allow them to do the follow-on checkout w/o having it do the build, but that's easy. Does anyone have a problem with me advocating this method? It still the standard classlib and DRLVM trees that a person can svn update, do diffs, create patches, and if a committer, checkin. But it places them in a very clear and useful on-disk relationship with each other, that can then be used for building the snapshot. FAQ This goes w/o saying what we're going to do :) First question will be How do I add a new FAQ entry? with a template for the xdoc. I was thinking that this should be hosted on the wiki, but there's something really nice about the permanence of the main site. Maybe the last entry on the site will be Where are tehre more FAQs? with a pointer to a wiki page, and then if people don't want to do patches to main page, they can enter them there, and we can harvest easily. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Andrey Chernyshev wrote:
On 9/21/06, Nathan Beyer [EMAIL PROTECTED] wrote:
From: Tim Ellison
snip
I'll add a factory/singleton method, which can be used then perform any
security checks. Then I presume other Classlib code would invoke this via
PrivilegedAction, correct?
The other option could be just to check that the class loader of the
calling method is the same as the one which was used to load Threads -
this is how it is done in the AccessorFactory. I suspect the
PriviledgedAction block would do eventually the same, but possibly
with some extra expense on creating the PriviledgedAction object.
Agreed, make the constructor private/default visibility then the
getSingleton() method can check...
if (VM.callerClassLoader() != null) { throw new SecurityException(); }
Do these need to be rearranged? Why can't we write the suncompat's
Unsafe equivalents in terms of these accessors?
Personally, I'm all for combining all of these down into one set of
interfaces in one module. It's really confusing to have all of these
different Object manipulation interfaces that seem alike, but are used in
different places.
I completely agree with this point of view.
The only 'duplication' of API behavior will be the functionality in the
o.a.harmony types and the sun.misc.Unsafe adapter. That is, let's
design the o.a.harmony types along the dimensions we want to distinguish
and write Unsafe in terms of those.
snip
I don't know the original intent that was put in the Unsafe design. My
only guesses would be:
To access the field in JNI code, you'd finally need the jfieldID. Then
the question comes - what to remember in the Java heap, 64-bit fieldID
or a Field object? The Field object is likely to consume more memory
in the Java heap compared to the long value.
Perhaps there could be also some pointer arithmetic with fieldID's
assuming that they are corresponding to the field offsets in the
object, and assuming that the layout of fields in the objects is
known. But I'm not sure if we want our classlib code be dependent on
that - ID's could be more abstract than the offsets.
No point in speculating, let's do the right thing for our needs.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
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][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Andrey Chernyshev wrote: On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote: Andrey Chernyshev wrote: Thanks Nathan! The Threads interface looks fine. Still, may be it would be nice if two different methods are allocated for parkNanos and parkUntil - passing the extra boolean parameter seems like an overhead, though very little. I agree, just create another method rather than passing in a boolean flag. How are you going to avoid apps calling these public methods? We can do a security/calling stack check on each method send, but it may be preferable to make Threads a singleton and check in a getSingleton() call. Yes, accessor classes were also designed as sigletones those instances can only be obtained through the AccessorFactory which handles the security checks. I wonder if it may make sense to have a single factory for accessor classes and Threads. Just let each type handle the security check. snip Do these need to be rearranged? Why can't we write the suncompat's Unsafe equivalents in terms of these accessors? I wouldn't wish we a have multiple classes which are doing the same things, even if some of them are delegating work to others (e.g. Objects is written on top of accessors or accessors are rewritten on top of Objects) - this seems to me just like extra layers/function calls. Agreed. I suggest that we have separate types for VM-specific vs. JNI based accessors so we can have a clean kernel code and common code split. As written elsewhere, the only delegation/adapter code will be from suncompat Unsafe to o.a.harmony types. plus the o.a.util.concurrent.Atomics [5] from the DRLVM. Yep, these need to be moved into the kernel for all VMs to implement. We can define them in (a new) concurrent-kernel unless there is consensus that they would be more generally useful, i.e. misc-kernel or luni-kernel. If all VM's are supposed to be 1.5+ compliant anyways, why not just adding to the luni-kernel... Because we want to keep the modularity of concurrency utils separate from LUNI. If there is no need for atomic/volatile operations outside the concurrency module, then we should put them into a concurrent-kernel. snip Andrey: did you check that everything in Objects is covered by existing accessor/atomics? Yes, the Objects is a subset of the existing accessors + Atomics combination. Then how about we delete 'Objects' and implement those parts of Unsafe in terms of existing ObjectAccessor methods? snip Do accessors need to be in kernel? They are implemented solely in terms of JNI - right? Right. It is clear that now we have a set of API's that provide different type of access to objects (e.g. simple, atomic or volatile), arrays and threads. I can imagine the following types of it's classification: - VM specific or not (or, can be implemented with JNI or not) yep, this is our kernel vs. common code distinction. - Package where they are needed (e.g. j.u.c, awt/swing, io or whatever) yep, we need to judge where the best place is for each type. Since they are o.a.harmony types the risk of putting them too 'low' (e.g. luni) is that they bloat the module where they are not actually used; and the risk of putting them too 'high' (e.g. swing) is that we create dependencies 'up' the semantic stack. In this instance I think we only need to decide between whether accessors go into luni, concurrent, and misc (maybe misc gets rolled into those two?). - Objects they are accessing (e.g. object, array, thread) Do you think we need this distinction in the type hierarchy? All accessors work on fundamental types, right? We may pick one or another type of classification and split the API into different pacakges/jars in accordance with it. On the other hand, obviously all of these classes would have the same mechanism for getting their instances, and most likely share the way how fieldID's (or offsets) are obtained. In other words, it may be unnatural to try to split them. This is why I proposed to keep them in a single place. If we can think of a usecase for volatile/atomic operations outside concurrent then I agree they go into luni luni-kernel. If we cannot then they are split into luni, concurrent, and concurrent-kernel. Assuming that there is a portion in this API set which is VM-specific, it probably may make sense to put them into kernel. ack +1 for Atomics moving into a kernel. Same comment as above for atomics etc. not being left as unguarded public types/methods to avoid surprises from mischievous apps. Right, I would add the Atomics creation to the AccessorFactory if we agreed that all of this stuff is of the same nature. Again, if they are all in the same component, then one factory is ok (but unnecessary imho) -- if they are in different components then let's not couple them at this point. What do you think? Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Nathan,
How about you move sun.misc.Unsafe from luni-kernel to suncompat -- it
may be confusing the design discussion by leaving it in there alongside
Threads/Objects.
Regards,
Tim
Nathan Beyer wrote:
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 8:11 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
for java.util.concurrent
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still, may be it
would be nice if two different methods are allocated for parkNanos and
parkUntil - passing the extra boolean parameter seems like an
overhead, though very little.
I agree, just create another method rather than passing in a boolean flag.
This sounds appropriate; I'll make an update to Threads.
How are you going to avoid apps calling these public methods? We can do
a security/calling stack check on each method send, but it may be
preferable to make Threads a singleton and check in a getSingleton() call.
I'll add a factory/singleton method, which can be used then perform any
security checks. Then I presume other Classlib code would invoke this via
PrivilegedAction, correct?
Another solution could be just to keep our own implementation of the
LockSupport in the luni-kernel (there is nothing to share for the
LockSupport with the original j.u.c, it contains almost no code). Is
there a reason why we can not do that?
Probably best to keep our own primitive operations separate in the
o.a.harmony package namespace.
I agree with Tim, but in addition to that I'd like to not fiddle with the
j.u.c code as much as possible, so as to ensure implementation consistency.
[2]
http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/
mo
dules/luni-
kernel/src/main/java/org/apache/harmony/kernel/vm/Objects.java
I guess the interesting question would be how do we rearrange the
already existing classes in Harmony, e.g. ObjectAccessor [3] and
ArrayAccessor [4] from the o.a.h.misc.accessors package of the
classlib,
Do these need to be rearranged? Why can't we write the suncompat's
Unsafe equivalents in terms of these accessors?
Personally, I'm all for combining all of these down into one set of
interfaces in one module. It's really confusing to have all of these
different Object manipulation interfaces that seem alike, but are used in
different places.
plus the o.a.util.concurrent.Atomics [5] from the DRLVM.
Yep, these need to be moved into the kernel for all VMs to implement.
We can define them in (a new) concurrent-kernel unless there is
consensus that they would be more generally useful, i.e. misc-kernel or
luni-kernel.
The proposed Objects seems like a combination of the above three.
For example, the following API set from the Objects:
public static long objectFieldOffset(Field field)
public static void putLong(Object object, long fieldOffset, long
newValue) {
public static long getLong(Object object, long fieldOffset)
is just equivalent to the one from the ObjectAccessor:
public final native long getFieldID(Field f);
public final native void setLong(Object o, long fieldID, long value);
public final native long getLong(Object o, long fieldID);
I agree. We should design the set the accessor/atomic methods that make
sense, then express the suncompat version of Unsafe in terms of them.
Andrey: did you check that everything in Objects is covered by existing
accessor/atomics?
Objects should cover everything that is in Atomics, but we'll need
additional methods to cover the accessor stuff, but that should be trivial.
I guess j.u.concurrent won't use the direct read/write to objects,
except for volatile or atomic access?
Having two different interfaces for doing the same can be confusing -
it may not be clear, what is the relationship between fieldID from
the accessors package and fieldOffset from the Objects.
Is there a big advantage to using longs rather than Field's directly?
It looks like the Atomics may have been that way once, the javadoc still
refers to '@parm field' though the signature is now 'long offset' g.
I would prefer working with Field objects, but we'll need the long offset
values to implement sun.misc.Unsafe. If you haven't looked at that API,
check it out, it's a little weird [1]. The way you manipulate fields is to
lookup the Field, then look up the offset, then you pass the instance and
field offset into the accessor/mutator methods. It's even more difficult for
arrays. You get the field offset, then you get a base offset and scalar
offset for the array field's type (int[], Object[]), which you then use to
calculate the actual element's offset (base + idx * scalar). Check out the
AtomicXXX classes for examples of usage [2].
[1]
http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/mo
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Geir Magnusson Jr. wrote: I do. what tool do you suggest? I use Eclipse and TortoiseSVN patch tools at different times. Both allow you to read a combined patch, but update only a subset of affected files. Like I said though, I don't feel strongly so recommending separate patches is ok by me if it helps others. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
+1
On Sep 21, 2006, at 5:56 PM, Tim Ellison wrote:
Nathan,
How about you move sun.misc.Unsafe from luni-kernel to suncompat -- it
may be confusing the design discussion by leaving it in there
alongside
Threads/Objects.
Regards,
Tim
Nathan Beyer wrote:
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 8:11 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object
manipulation
for java.util.concurrent
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still, may be it
would be nice if two different methods are allocated for
parkNanos and
parkUntil - passing the extra boolean parameter seems like an
overhead, though very little.
I agree, just create another method rather than passing in a
boolean flag.
This sounds appropriate; I'll make an update to Threads.
How are you going to avoid apps calling these public methods? We
can do
a security/calling stack check on each method send, but it may be
preferable to make Threads a singleton and check in a getSingleton
() call.
I'll add a factory/singleton method, which can be used then
perform any
security checks. Then I presume other Classlib code would invoke
this via
PrivilegedAction, correct?
Another solution could be just to keep our own implementation of
the
LockSupport in the luni-kernel (there is nothing to share for the
LockSupport with the original j.u.c, it contains almost no
code). Is
there a reason why we can not do that?
Probably best to keep our own primitive operations separate in the
o.a.harmony package namespace.
I agree with Tim, but in addition to that I'd like to not fiddle
with the
j.u.c code as much as possible, so as to ensure implementation
consistency.
[2]
http://svn.apache.org/repos/asf/incubator/harmony/enhanced/
classlib/trunk/
mo
dules/luni-
kernel/src/main/java/org/apache/harmony/kernel/vm/Objects.java
I guess the interesting question would be how do we rearrange the
already existing classes in Harmony, e.g. ObjectAccessor [3] and
ArrayAccessor [4] from the o.a.h.misc.accessors package of the
classlib,
Do these need to be rearranged? Why can't we write the suncompat's
Unsafe equivalents in terms of these accessors?
Personally, I'm all for combining all of these down into one set of
interfaces in one module. It's really confusing to have all of these
different Object manipulation interfaces that seem alike, but are
used in
different places.
plus the o.a.util.concurrent.Atomics [5] from the DRLVM.
Yep, these need to be moved into the kernel for all VMs to
implement.
We can define them in (a new) concurrent-kernel unless there is
consensus that they would be more generally useful, i.e. misc-
kernel or
luni-kernel.
The proposed Objects seems like a combination of the above three.
For example, the following API set from the Objects:
public static long objectFieldOffset(Field field)
public static void putLong(Object object, long fieldOffset, long
newValue) {
public static long getLong(Object object, long fieldOffset)
is just equivalent to the one from the ObjectAccessor:
public final native long getFieldID(Field f);
public final native void setLong(Object o, long fieldID, long
value);
public final native long getLong(Object o, long fieldID);
I agree. We should design the set the accessor/atomic methods
that make
sense, then express the suncompat version of Unsafe in terms of
them.
Andrey: did you check that everything in Objects is covered by
existing
accessor/atomics?
Objects should cover everything that is in Atomics, but we'll need
additional methods to cover the accessor stuff, but that should be
trivial.
I guess j.u.concurrent won't use the direct read/write to objects,
except for volatile or atomic access?
Having two different interfaces for doing the same can be
confusing -
it may not be clear, what is the relationship between fieldID
from
the accessors package and fieldOffset from the Objects.
Is there a big advantage to using longs rather than Field's
directly?
It looks like the Atomics may have been that way once, the
javadoc still
refers to '@parm field' though the signature is now 'long offset'
g.
I would prefer working with Field objects, but we'll need the long
offset
values to implement sun.misc.Unsafe. If you haven't looked at that
API,
check it out, it's a little weird [1]. The way you manipulate
fields is to
lookup the Field, then look up the offset, then you pass the
instance and
field offset into the accessor/mutator methods. It's even more
difficult for
arrays. You get the field offset, then you get a base offset and
scalar
offset for the array field's type (int[], Object[]), which you
then use to
calculate the actual element's offset (base + idx * scalar). Check
out the
AtomicXXX classes for examples of usage [2].
[1]
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
On 9/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Weldon, Robin
thank you for the comments.
There are just a few steps left to do before Jitrino.OPT will have
usable
unboxed package implementation.
Right now I'm working on atomic operations (prepare/attempt pair), and I
do
not completely understand the semantic of the 'prepare' method.
The prepareXYZ method looks like a simple load and is not an atomic
operation by itself. Are there any examples that describe these
operations
in details?
Robin will correct me if I am wrong.
I think the idea is that this is a generic API intended to be used for
accessing compare and swap facilities on a bunch of different hardware.
And the actual hardware has different memory models, different CAS
semantics, etc.
Basically the generic facility needed is to first read the CAS target
memory
location (this is the prepare). If the memory is sitting at a specific
value (this is the do something), then do an attempt as follows:
old_contents = CAS(expected_specfic_value_that_I_just_read,
some_new_value,
target_memory_location)
If the old_contents are identical to
expected_specific_value_that_I_just_read, we know that the CAS succeeded.
In other words, you won the competition. Otherwise you lost.
I imagine the following situation in user's code:
prepareXYZ()
do something
attempt()
Is this code correct?
You're correct.
The prepare/attempt was designed to match architectures (PPC, Alpha ...)
with a load-locked/store-conditional instruction pair.
The standard code fragment for a synchronized update is
do {
oldVal = x.prepare();
newVal = f(oldVal);
} while (!x.attempt(oldVal,newVal));
As an aside, vmmagic should probably have CAS as a primitive rather than
prepare/attempt, but I don't think that's going to happen in the immediate
future.
cheers
-
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] Build problems - missing bfd.h
Geir Magnusson Jr. wrote: On Sep 21, 2006, at 1:09 AM, Robin Garner wrote: Trying to build the latest trunk (r448461) on Ubuntu (6.06). That's my main build platform. No need to hack anything. Had to hack build.sh because the ant executable isn't in ANT_HOME, That's weird. You shouldn't have to do that. These fragments from build.sh: # Apache Ant 1.6.2 or higher (can be obtained at http://ant.apache.org) if [ -z $ANT_HOME ]; then ANT_HOME=$EXTERNAL_DIR/common/apache-ant-1.6.5-bin/apache-ant-1.6.5 fi ... elif [ ! -x $ANT_HOME/bin/ant ]; then echo * File $ANT_HOME/bin/ant not found. echo * Make sure you have Ant 1.6.5 or above installed from echo * http://ant.apache.org/bindownload.cgi and that ANT_HOME environment echo * variable points out to the Ant installation dir, e.g. echo * export ANT_HOME=/usr/local/ant_1.6.5 ERROR fi ... export ANT_HOME=`(cd $ANT_HOME;pwd)` ... ANT_COMMAND=$ANT_HOME/bin/ant --noconfig seems to indicate otherwise, if you want to use the default ubuntu ant install. Doing export ANT_HOME=`(cd $ANT_HOME;pwd)` seems a bit *cough* 'suboptimal' :) and add a URL to download xalan No need to do that either. The xalan problem means that DRLVM wasn't finding the classlib tree correctly, where the Xalan dep is. By default, DRLVM assumes that classlib and it are arranged on the filesystem as they are in SVN : enhanced/ classlib/ trunk/ drlvm/ trunk/ but if you are using the federated build that is enhanced/trunk, then the relationship is different. The best way is to look at build/drlvm.properties.example, copy to build/drlvm.properties and adjust so it's right. Ah ... yep, works a treat. , but now the build fails with a missing bfd.h (full error message below). you need to install binutils for bfd, IIRC. binutils-dev does the trick. Thanks, Robin Any pointers ? cheers, Robin -- build.native.c: [cc] Starting dependency analysis for 10 files. [cc] 10 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 2 total files to be compiled. [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:21:17: error: bfd.h: No such file or directory [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:22:21: error: dis-asm.h: No such file or directory [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:63: error: syntax error before ‘fprintf_ftype’ [cc] cc1: warnings being treated as errors [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:65: warning: ‘struct disassemble_info’ declared inside parameter list [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:65: warning: its scope is only this definition or declaration, which is probably not what you want [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:70: error: field ‘bfd_info’ has incomplete type [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: error: syntax error before ‘bfd_decoder’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: warning: initialization makes integer from pointer without a cast [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:81: warning: data definition has no type or storage class [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:89: error: syntax error before ‘src’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function ‘disasm_read_memory’: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: ‘buffer’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: (Each undeclared identifier is reported only once [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: for each function it appears in.) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: ‘src’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:94: error: ‘n’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: At top level: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:103: error: syntax error before ‘memaddr’ [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c: In function ‘disasm_print_adress_default’: [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:105: error: ‘info’ undeclared (first use in this function) [cc] /home/robing/harmony/drlvm/vm/port/src/disasm/linux/disasm.c:105: error: ‘memaddr’ undeclared (first use in this function) [cc]
Re: [doc] Why do we have boxes drawn around source now?
On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Is this new? We now have boxes drawn around the shaded box on a source document snippet... Maybe because we now have unified site.css (HARMONY-1384[1]) to make our pages more beautiful ;-) [1] http://issues.apache.org/jira/browse/HARMONY-1384 Best regards, Richard 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 - 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] NPE is thrown when the kernel tests are run on Windows at revision 448448
Geir Magnusson Jr. wrote: Do you think this is a drlvm issue or a classlib issue? I guess it is an integration issue, i.e., ICU4J's UCharacter needs to load some resources for initialization, while at that time on DRLVM, some necessary kernel classes haven't been inited, so that the UCharacter cannot load these properties sucessfully and leave them to null. I'll roll back the patch for Character temporarily if no one objects, and will look inside later(I need to checkout ICU4J's source at first ...). geir On Sep 21, 2006, at 1:07 AM, Vladimir Gorr wrote: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty(UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle.init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. Thanks, Vladimir. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang 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]
Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:291: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:462: Warning: Could not find file C:\spark\drlvm\trunk\build\make\no_settings_in_config_or_environment to copy. This is the first time I build DRLVM, would you give me some hint about this error message. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL PROTECTED] Best regards Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty (UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- 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]
