Re: [drlvm] Extending ‘org.vmmagic.unboxed’ package with native calls and TLS access
On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Mikhail, Please see inline. 2) How will JIT know if to use magic helpers? The one option is to pass cmd-line parameter, like - Djit.use_magic_vmhelpers=on. This option could be placed into the EM configuration file as any other JIT option. Could use both ? Yes, all of the JIT options in EM configuration file are simple -Djit... Java properties and could be overriden from the command line. 4) How to detect native helper calling convention? We can use one of the approaches JUnit uses: a) check the prefix for the method: stdcall_new(..), cdecl_new(): b) check the Java annotation for the method. I prefer to use approach a). But the only reason for that is that I'm not sure DRLVM has interface to access to the class annotations today. Could VM gurus correct me? We had discussed this elsewhere and annotations look cleaner. Annotations should be obtainable via reflection methods get/resolve_annotations() on the class, but Alexey V could confirm. We could have a default like cdecl and even use this exclusively initially, unless you want to use a custom platform independent JIT calling convention Ok, I'll use annotation if we support them. 6) Where to keep and which classloader to use to load unboxed + helpers Java code? Would it be part of the kernel classes and loaded by bootstrap classloader? I vote leave it outside of the kernel class. But this way could cause security problems in future. Any other opinion? I did not really understand why you are recommending leaving them out of the boot loader set. I changed my opinion after posting this proposal. Once VM helpers are internals of VM we should protect them and use only boot classloader to load them. I'm going to implement the first helper today/tomorrow. I know that while doing it there will more problems arise and I'll report them to discuss. -- Mikhail Fursov
Re: [drlvm] Extending ‘org.vmmagic.unboxed’ package with native calls and TLS access
Mikhail, It all seems reasonable. Regarding #6. Maybe I misunderstand what you are saying but it seems best to put the java vmhelpers in the same isolation as other security sensitive kernel classes. On 10/10/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Mikhail, Please see inline. On 10/9/06, Mikhail Fursov [EMAIL PROTECTED] wrote: All, We have 'org.vmmagic.unboxed' package (address arithmetic) support in both Jitrino.OPT and Jitrino.JET compilers today. So we can rewrite part of our VM helper's fast paths in Java and teach JIT compiler to inline it. The only thing is left to do is to get the answers to the following questions: 1) What is the default package for the fast path helpers? My proposal is 'org.harmony.vmhelper'. Sounds reasonable 2) How will JIT know if to use magic helpers? The one option is to pass cmd-line parameter, like - Djit.use_magic_vmhelpers=on. This option could be placed into the EM configuration file as any other JIT option. Could use both ? 3) How to call a slow native helper's version from the fast-path part of the helper written in Java? The proposal is to create package like 'org.harmony.vmhelper.native' with stub methods for all native helpers. Once such a method is called from Java, JIT will replace it with a real native helper call. In this case we need to have a mapping between magic and native helpers on JIT or VM side. This is a good idea. I think the VM needs to do this housekeeping, since it provides the stubs of regular helpers to the JIT anyway 4) How to detect native helper calling convention? We can use one of the approaches JUnit uses: a) check the prefix for the method: stdcall_new(..), cdecl_new(): b) check the Java annotation for the method. I prefer to use approach a). But the only reason for that is that I'm not sure DRLVM has interface to access to the class annotations today. Could VM gurus correct me? We had discussed this elsewhere and annotations look cleaner. Annotations should be obtainable via reflection methods get/resolve_annotations() on the class, but Alexey V could confirm. We could have a default like cdecl and even use this exclusively initially, unless you want to use a custom platform independent JIT calling convention 5) How to access to TLS data from Java? The last agreement was something like public static Address TLS.getAddress() method. We can put TLS class to the package with all of native VM helpers stubs (see item 3 for details) 6) Where to keep and which classloader to use to load unboxed + helpers Java code? Would it be part of the kernel classes and loaded by bootstrap classloader? I vote leave it outside of the kernel class. But this way could cause security problems in future. Any other opinion? I did not really understand why you are recommending leaving them out of the boot loader set. All of the tasks above are rather easy to implement. But we have to come to the agreement before coding. Please, suggest your vision or ask me if something I wrote is unclear. + The first candidates for inlining are: allocation helpers, monitor helpers, write barriers. Any other ideas? -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division
Re: [DRLVM][JET] write barrier for Java (mmtk)
Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier. Sorry for the confusion. On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread [drlvm]Extending... This helper (a static method) can be inlined by JIT without any devirtualization and call any method needed from MMTk or native implementation. So JIT won't know if it works with MMTk or with a native GC: all you need is just to replace the Java version of the helper. ? -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division
Re: [drlvm] Extending ‘org.vmmagic.unboxed’ package with native calls and TLS access
Yes, I'm agree we should protected them (In the initial letter I was not sure) + We have to divide the helpers into the groups: VM helpers, GC helpers. So switching to the different type of GC version only GC helpers implementation will be changed. But this means that GC must provide some of the kernel classes. This is the problem I think. On 10/11/06, Weldon Washburn [EMAIL PROTECTED] wrote: It all seems reasonable. Regarding #6. Maybe I misunderstand what you are saying but it seems best to put the java vmhelpers in the same isolation as other security sensitive kernel classes. -- Mikhail Fursov
Re: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target
On 11 October 2006 at 3:14, Gregory Shimansky [EMAIL PROTECTED] wrote: On Monday 09 October 2006 19:54 Oliver Deakin wrote: I see that you already said pretty much the same thing I did on another thread [1]. IMHO we should make sure that if the fetch-depends target finds it cannot sym link to preinstalled system libraries, then the user is clearly informed so they have the choice to install them without having the archived file versions unpacked. So perhaps the fetch-depends step should still fail with a message saying something like Could not resolve these dependencies, either build/install these packages manually or you can run this other target to have the archived versions unpacked into your dependency tree. (Hopefully a little clearer than that ;) ) This sounds very much like a configure script. Indeed, and we may well end up with one of those at some point. Check for installed libraries, fail if something is missing. I like it :) I would like to be more helpful if we can. Yesterday, I added the details of the required packages for Fedora Core 5. Hopefully others will help get the instructions up dated for distributions they use. Otherwise, I will try to add instructions for recent SLES and RHEL in the next week or so. On Linux however all libraries are present in distributions (I buy you a beer if you name a single Linux distribution which doesn't include necessary development packages, knoppix not counted). I'll get my better half to start making more room in the fridge while I go through the list of distros at: http://lwn.net/Distributions/ I reckon I should get at least a six-pack just out of the embedded section alone. ;-) Only Windows distribution doesn't include them, so for convenience windows binaries may be cached for download on harmony site. In time I expect we'll do the same for others like MacOS X, Aix, etc. Regards, Mark. - 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] VM throws NullPointerException in case java.class.path is not set
Oliver,
HARMONY-1818 was created to track this issue. Could you attach your
test case (simple launcher) to it?
Thanks
Evgueni
On 10/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Absolutely. And if not, even the principle of be kind to your users
dictates that we do something nice for them.
geir
Evgueni Brevnov wrote:
Oliver,
You have provided strong arguments that RI uses current directory by
default. I think it makes sense to be compatible with RI in this
particular case.
Thanks
Evgueni
On 10/10/06, Oliver Deakin [EMAIL PROTECTED] wrote:
I have just tried launching the RI with a simple launcher (very basic -
CreateJavaVM(),
finds and launches a class, then calls DestroyJavaVM()). The launcher
does not
set java.class.path, and executes the main method of the following class:
public class SysInfo {
public static void main(String[] args) {
System.getProperties().list(System.out);
}
}
The java.class.path value is printed as:
java.class.path=
So it appears that java.class.path property is left empty by default.
However,
to have found the SysInfo class, the RI must have searched in the current
directory. I can also instantiate other classes that are located in the
current
directory. So although the java.class.path is set to an empty string,
internally
there is a default inclusion of the current directory.
IMHO we follow the RI behaviour here, and have an implicit inclusion of
the current directory unless the classpath is explicitly set.
Regards,
Oliver
Evgueni Brevnov wrote:
It seems for me like pretty specified VM behavior to treat classpath
absence as take classes from current directory. At least RI does like
that when you don't specify classpath on command line.
Evgueni
On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Another solution could be a simple shutdown with the valid error
message.
Sometimes the error message is better than hidden behaviour.
So the alternative is to check all properties VM needs before running
real
startup and fail if some of the properties are not found.
On 10/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Hi All,
Currently DRLVM starts with help of the launcher. The launcher
does a
lot of stuff required to create VM instatnce. As a part of its
job it
sets up java.class.path property. And this is good. What is not good
that DRLVM crashes (actually throws NullPointerException in
initalization stage) if java.class.path is not set. I believe it
makes
sense to point java.class.path to current directory inside VM if
launcher doesn't set it.
What do u think?
Thanks
Evgueni
-
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
-
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]
-
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: [build] DRLVM build on Windows
2006/10/10, Salikh Zakirov [EMAIL PROTECTED]: Alexey Petrenko wrote: Salikh, I've posted the last few lines from the output. There is no compiler call. And the error message is the same with the mentioned in the first letter: Ah, I see now. The compiler was never called, and the error is likely to be printed by cctask. It looks like some cctask issue. By the way, grepping for the error message, I found this http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] :) Salikh, this old instruction helped! :) Thanks for finding it. SY, Alexey Some more things to check 1) Maybe you have older version of cpptasks.jar in ant/lib? - If yes, remove it 2) Maybe the version that 'build.bat update' placed to build/make/tmp is not 1.0b4? - Download real 1.0b4 version from http://ant-contrib.sourceforge.net/ and compare with the cpptasks.jar in build/make/tmp. - If different, remove build/make/tmp and re-run 'build.bat update' If this all still doesn't help, I'd say we're screwed with respect to the build system. - 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]
[classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription
Hello, The test fails on Windows XP when the locale-setting is zh_CN. It's because that view.getSystemTypeDescription(file) returns Chinese words 文件 instead of File. Could any one help to verify this issue? Thanks a lot. -- 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] Should the launcher print uncaught exceptions?
Oliver,
I created https://issues.apache.org/jira/browse/HARMONY-1819 with
suggested fix. Please, look at and update it if DetachCurrentThread is
required before DestroyJavaVM for some reason.
Thanks
Evgueni
On 9/22/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 9/22/06, Oliver Deakin [EMAIL PROTECTED] wrote:
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.
Sure, I checked both cases work fine on my implementation of
InvocationAPI for DRLVM (with DetachCurrentThread and without it). So
the launcher can choose either to detach the main thread or not...
Thanks
Evgueni
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
RE: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription
Hello, Richard, I'll take a look at it. Thanks, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 12:06 PM To: harmony-dev@incubator.apache.org Subject: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription Hello, The test fails on Windows XP when the locale-setting is zh_CN. It's because that view.getSystemTypeDescription(file) returns Chinese words 文件 instead of File. Could any one help to verify this issue? Thanks a lot. -- 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] - 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][JET] write barrier for Java (mmtk)
Weldon, I'm a bit confused what to call finally... The previous WB4J version did a call to org/mmtk/plan/PlanLocal::writeBarrier(). The problem was with getting an instance of PlanLocal. We solved it by adding a stub static method PlanLocal::getPlanLocal() - just for the sake of testing functionality. In the latest version (HARMONY-1806) I'm doing a call to static Barriers::performWriteInBarrier(). However, as long as this method is presented in old MMTk javadoc, I could not find it in the MMTk/ sources from Harmony svn. Also, looking into MMTk/ I could not find a PlanLocal class either. The javadoc says that writeBarrier() is only presented in xxMutator classes. I was about to call org.mmtk.vm::barriers::writeInBarrier() but just saw your post. So, now I'm a in deep thoughts on which method to call and what instance to use. :-) Could please give me a clue? -- Thanks, Alex Weldon Washburn wrote: Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier. Sorry for the confusion. On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread [drlvm]Extending... This helper (a static method) can be inlined by JIT without any devirtualization and call any method needed from MMTk or native implementation. So JIT won't know if it works with MMTk or with a native GC: all you need is just to replace the Java version of the helper. ? -- 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: [testing] test suite layout, testNG, and more
On 10/9/06, Richard Liang [EMAIL PROTECTED] wrote: On 10/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: What is the status of our discussions about new test suite layout? Long ago we decided not to move existing tests until we finish with that discussion but the discussion seems to be either dead or in coma It's not dead ;-) We are waiting for the completion of j.u.concurrent so that we could run a pilot and continue our discussion. Looking forward to ... btw, Harmony may also benifit from failure and rerun feature of TestNG. I believe developers will like it! Does it make sense to continue putting the tests in order (according to the old model) and relayout them as soon as we finish the discussion? Yes, it does make sense. Before we draw any new conclusion about TestNG, I suggest we follow our existing testing conventions/guidelines. Thanks, Mikhail - 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] -- Best regards, Andrew Zhang
RE: Can't get binary to work
Seemed promising, but this patch did not help. I ran java -Xtrace helloworld to see if it even got to the patched code, but it seems like my code hangs even before getting to that code. I'm really not sure what my next step is to try to get the VM up and running correctly. Armand -Original Message- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 1:54 AM To: harmony-dev@incubator.apache.org Subject: Re: Can't get binary to work 2006/10/9, Armand Navabi [EMAIL PROTECTED]: Yes, I am still having problems. Like I said, I am just trying to run the executable currently. I see the same problem I was seeing when I built the DRLVM. I downloaded the Latest Linux JRE snapshot build, set the JAVA_HOME, PATH and LD_LIBRARY_PATH environment variables and then tried to run helloworld. Sometimes the executable will print hello world! and then hang, and sometimes it will just hang. Same thing happens when I download and try to run the Latest Linux HDK with helloworld. Armand, The symptoms you are describing similar to investigation results of HARMONY-1816. It is interesting to see if the patch helps you. [0] http://issues.apache.org/jira/browse/HARMONY-1816 My platform is Linux Gentoo 2.6.17.8. Thanks, Armand -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Sunday, October 08, 2006 6:57 PM To: harmony-dev@incubator.apache.org Subject: Re: Can't get binary to work Are you still having problems Armand? Tim Armand Navabi wrote: I have been unable to figure out why I can't get the drlvm to run helloworld. The classlib with Intel's VM works fine. So now I thought I'd just see if I could download the binary and execute it (JRE), but it is behaving the same way (I guess this is to be expected, but I just wanted to make sure it wasn't something in the build process that was causing the trouble). When I run java by itself it executes without problem, when I run java helloworld it just hangs, and java -showversion will print version info and then hang right after that: [EMAIL PROTECTED] /scratch/anavabi/Harmony/harmony-jre-r450941/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 = r450941, (Sep 28 2006), Linux/ia32/gcc 3.4.6, release build http://incubator.apache.org/harmony (hangs here) Here are the environment variables that I think are relevant: LD_LIBRARY_PATH /scratch/anavabi/Harmony/harmony-jre-r450941/bin:/scratch/anavabi/Harmony/ha rmony-jre-r450941/bin/default/ PATH .:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/i686-pc-linux-gnu/gcc-bi n/3.4.6:/opt/ICAClient:/opt/sun-jdk-1.5.0.06/bin:/opt/sun-jdk-1.5.0.06/jre/b in:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/opt/eclipse-sdk-3.2.1 JAVA_HOME /scratch/anavabi/Harmony/harmony-jre-r450941/bin I'm on Gentoo 2.6.17.8. Any ideas what may be going on? Thanks, Armand -- 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] - 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] VM throws NullPointerException in case java.class.path is not set
ok, done - thanks for opening the JIRA Evgueni.
Regards,
Oliver
Evgueni Brevnov wrote:
Oliver,
HARMONY-1818 was created to track this issue. Could you attach your
test case (simple launcher) to it?
Thanks
Evgueni
On 10/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Absolutely. And if not, even the principle of be kind to your users
dictates that we do something nice for them.
geir
Evgueni Brevnov wrote:
Oliver,
You have provided strong arguments that RI uses current directory by
default. I think it makes sense to be compatible with RI in this
particular case.
Thanks
Evgueni
On 10/10/06, Oliver Deakin [EMAIL PROTECTED] wrote:
I have just tried launching the RI with a simple launcher (very
basic -
CreateJavaVM(),
finds and launches a class, then calls DestroyJavaVM()). The launcher
does not
set java.class.path, and executes the main method of the following
class:
public class SysInfo {
public static void main(String[] args) {
System.getProperties().list(System.out);
}
}
The java.class.path value is printed as:
java.class.path=
So it appears that java.class.path property is left empty by default.
However,
to have found the SysInfo class, the RI must have searched in the
current
directory. I can also instantiate other classes that are located
in the
current
directory. So although the java.class.path is set to an empty string,
internally
there is a default inclusion of the current directory.
IMHO we follow the RI behaviour here, and have an implicit
inclusion of
the current directory unless the classpath is explicitly set.
Regards,
Oliver
Evgueni Brevnov wrote:
It seems for me like pretty specified VM behavior to treat
classpath
absence as take classes from current directory. At least RI does
like
that when you don't specify classpath on command line.
Evgueni
On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Another solution could be a simple shutdown with the valid error
message.
Sometimes the error message is better than hidden behaviour.
So the alternative is to check all properties VM needs before
running
real
startup and fail if some of the properties are not found.
On 10/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Hi All,
Currently DRLVM starts with help of the launcher. The launcher
does a
lot of stuff required to create VM instatnce. As a part of its
job it
sets up java.class.path property. And this is good. What is
not good
that DRLVM crashes (actually throws NullPointerException in
initalization stage) if java.class.path is not set. I believe it
makes
sense to point java.class.path to current directory inside VM if
launcher doesn't set it.
What do u think?
Thanks
Evgueni
-
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
-
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]
-
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]
--
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]
Re: [classlib] [tests] Can anyone explain what these are for?
I've written a script to search all the statements like that:
#!/usr/bin/perl -w
use File::Find;
use DirHandle;
use strict;
my $dir = $ARGV[0] || die need input a dir\n;
chomp $dir;
processDir($dir);
sub processDir {
my $folder = $_[0];
my $dh = DirHandle-new($folder) || die can not open directiony: $!\n;
foreach my $f ($dh-read()) {
next if ($f=~/^\.$|^\.\.$|^\..*$/);
if (-d $folder\/$f){
processDir($folder\/$f);
}
if ($f=~/^.*Test\.java$/){
processFile($folder\/$f);
}
}
}
sub processFile {
my $f = $_[0];
my $lineNum = 1;
my $line=;
open (MYFILE,$f) || die can not open file: $!\n;
while ($line=MYFILE){
chomp $line;
if ($line=~/^\s*assertTrue.*true\s*\)\s*;\s*$/){
print $f:$lineNum\n;
}
$lineNum = $lineNum +1;
}
}
And found 88 statements like that in current classlib, then record them in
[1].
We can check them.
[1].http://wiki.apache.org/harmony/Invalid_assertTrue
On 10/11/06, Richard Liang [EMAIL PROTECTED] wrote:
On 10/11/06, Nathan Beyer [EMAIL PROTECTED] wrote:
Perhaps, but there are much better ways of determining that. From just
reading the test code to code coverage tools.
From my analysis, these were part of the large test contribution and
indicated that there wasn't an explicit test for that method. In most
cases, there were tests for these methods, either in other classes or
in other methods of the class.
Nathan, I agree ;-)
-Nathan
On 10/10/06, Richard Liang [EMAIL PROTECTED] wrote:
On 10/11/06, Nathan Beyer [EMAIL PROTECTED] wrote:
I've seen a few and I've deleted any that I've come across. I would
say feel free to delete them too. I've also been deleting empty
setup
and teardown methods too.
Please do not simply delete them. Maybe that means we are lack of the
test for some methods, for example getInetAddress.
-Nathan
On 10/10/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
These could be a result of copy/paste tests creation.
And I'm curious why it was written for the first time. :)
SY, Alexey
2006/10/10, Mark Hindess [EMAIL PROTECTED]:
I've come across a couple of tests with things like:
public void test_getInetAddress() {
assertTrue(Used to test, true);
}
Can anyone explain why we have these?
Regards,
Mark.
-
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]
--
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]
-
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]
--
Robert Hu
China Software Development Lab, IBM
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
Geir Magnusson Jr. wrote:
Absolutely. And if not, even the principle of be kind to your users
dictates that we do something nice for them.
Agreed - being nice to the user where we can is a good thing! Having the
current directory on the classpath is pretty common - giving it to the
user by default costs nothing and saves them having to explicitly set it
in every launcher they write.
Regards,
Oliver
geir
Evgueni Brevnov wrote:
Oliver,
You have provided strong arguments that RI uses current directory by
default. I think it makes sense to be compatible with RI in this
particular case.
Thanks
Evgueni
On 10/10/06, Oliver Deakin [EMAIL PROTECTED] wrote:
I have just tried launching the RI with a simple launcher (very basic -
CreateJavaVM(),
finds and launches a class, then calls DestroyJavaVM()). The launcher
does not
set java.class.path, and executes the main method of the following
class:
public class SysInfo {
public static void main(String[] args) {
System.getProperties().list(System.out);
}
}
The java.class.path value is printed as:
java.class.path=
So it appears that java.class.path property is left empty by default.
However,
to have found the SysInfo class, the RI must have searched in the
current
directory. I can also instantiate other classes that are located in the
current
directory. So although the java.class.path is set to an empty string,
internally
there is a default inclusion of the current directory.
IMHO we follow the RI behaviour here, and have an implicit inclusion of
the current directory unless the classpath is explicitly set.
Regards,
Oliver
Evgueni Brevnov wrote:
It seems for me like pretty specified VM behavior to treat classpath
absence as take classes from current directory. At least RI does like
that when you don't specify classpath on command line.
Evgueni
On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Another solution could be a simple shutdown with the valid error
message.
Sometimes the error message is better than hidden behaviour.
So the alternative is to check all properties VM needs before
running
real
startup and fail if some of the properties are not found.
On 10/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Hi All,
Currently DRLVM starts with help of the launcher. The launcher
does a
lot of stuff required to create VM instatnce. As a part of its
job it
sets up java.class.path property. And this is good. What is not
good
that DRLVM crashes (actually throws NullPointerException in
initalization stage) if java.class.path is not set. I believe
it makes
sense to point java.class.path to current directory inside VM if
launcher doesn't set it.
What do u think?
Thanks
Evgueni
-
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
-
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]
-
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]
Re: [DRLVM][JET] write barrier for Java (mmtk)
I think you must be looking at a fairly old version of MMTk. writeBarrier is an instance method of a MutatorContext (in org.mmtk.plan). MutatorContext exists to hold unsynchronized thread-local data structures. Particularly relevant to the write barrier, each mutator context has its own thread-local remset. All of the mutator context methods of MMTk need fast access to the MMTk thread local data structures, which is why they are instance methods. The other critical instance method of a MutatorContext is 'alloc', which also has it's thread-local chunk of the space(s) it allocates into. As far as the VM is concerned, it will be calling instance methods of a final class. The various classes in org.mmtk.plan.* aren't final, but the VM interface code is expected to wrap the currently selected plan in some final class. JikesRVM wraps the currently selected plan classes in a 'SelectedPlan', 'SelectedMutatorContext' etc. As far as the VM.barriers.performWriteInBarrier() call is concerned, the optimization required to devirtualize a call to a final method of a static final field shouldn't be too hard to implement. MMTk recently moved away from using static methods for this part of the interface, to the current abstract factory, and improved the structure of the software significantly. We don't want to go back! I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. well, it less 'breaks the architecture' than performs a no-op :) -- robin Weldon Washburn wrote: Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier. Sorry for the confusion. On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread [drlvm]Extending... This helper (a static method) can be inlined by JIT without any devirtualization and call any method needed from MMTk or native implementation. So JIT won't know if it works with MMTk or with a native GC: all you need is just to replace the Java version of the helper. ? -- 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: [build] DRLVM build on Windows
This should be listed somewhere under Gotchas while building DRLVM. It would be useful to have these helpful tips stored for future Harmony contributors. I see there are already some useful DRLVM docs on the website - perhaps some kind of build troubleshooting section would also be good? Regards, Oliver Alexey Petrenko wrote: 2006/10/10, Salikh Zakirov [EMAIL PROTECTED]: Alexey Petrenko wrote: Salikh, I've posted the last few lines from the output. There is no compiler call. And the error message is the same with the mentioned in the first letter: Ah, I see now. The compiler was never called, and the error is likely to be printed by cctask. It looks like some cctask issue. By the way, grepping for the error message, I found this http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] :) Salikh, this old instruction helped! :) Thanks for finding it. SY, Alexey Some more things to check 1) Maybe you have older version of cpptasks.jar in ant/lib? - If yes, remove it 2) Maybe the version that 'build.bat update' placed to build/make/tmp is not 1.0b4? - Download real 1.0b4 version from http://ant-contrib.sourceforge.net/ and compare with the cpptasks.jar in build/make/tmp. - If different, remove build/make/tmp and re-run 'build.bat update' If this all still doesn't help, I'd say we're screwed with respect to the build system. - 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]
[classlib][util.prefs] Implementation should be compatible with RI
Hi all, org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest fails on some machines when there are restrictions in access to system registry. https://issues.apache.org/jira/browse/HARMONY-1751 describes the issue. It looks like Harmony implementation does not follow spec for Preferences.systemNodeForPackage(). Besides, the test is incorrect as well because it does not expect java.util.prefs.BackingStoreException on Preferences.childrenNames() and fails on RI. Could anyone look into the issue? -- Thanks, Elena
Re: [classlib][build] Failed to build classlib on r454714
Just to assure that the fix Mark did is good - lcms1.0.12 works fine for me, all unit tests pass on J9. 2006/10/10, Mark Hindess [EMAIL PROTECTED]: On 10 October 2006 at 12:23, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Muahaha... didn't you just say this was something that never changed, was geological in stability, etc, etc? :) :-) Well, yeah, and I was worried until I saw that: a) the change to introduce this variable happened over two years ago, and b) my lucky guess was enough to fix it -Mark. Mark Hindess wrote: On 10 October 2006 at 16:22, Oleg Khaschansky [EMAIL PROTECTED] om wrote: It looks like you don't have lcms.h and, probably, other lcms stuff in Harmony\enhanced\classlib\trunk\depends\libs\build\lcms\. I think the problem is more likely that they do have lcms but that they don't have the same version as everyone else. At a guess, I'd say that the version they are using doesn't have the cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and that: #ifndef cmsFLAGS_NOTCACHE #define cmsFLAGS_NOTCACHE (0) #endif after the #include for lcms.h would solve the problem. But this is a complete guess. -Mark. Recently awt/swing build was enabled by default and it requires this dependency as well as png and jpeg. Read the instructions in Harmony\enhanced\classlib\trunk\depends\libs\build\README.txt. Or check the recent posts about this. E.g. the following recent thread: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: I'm seeing the same problem. Thanks, Pavel On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Got the following compilation error (SLES 9 gcc 3.3.3): build-native: [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/e xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include -I/export/users2/avarlamo/l inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic -Icommon -I../shared//i nclude -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depends / libs/build/lc ms -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTran s form': [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE' undeclared (first use in th is function) [exec] ../shared/cmmxforms.c:150: error: (Each undeclared identifier is reported only on ce [exec] ../shared/cmmxforms.c:150: error: for each function it appear s in.) [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of `cmsSample3DGrid' from incom patible pointer type [exec] make: *** [../shared//cmmxforms.o] Error 1 BUILD FAILED - 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] - 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: [classlib][build] Failed to build classlib on r454714
Thanks, Alexey! I though I need to install a newer lcms - now I'm happy to live with that. -Pavel On 10/11/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Just to assure that the fix Mark did is good - lcms1.0.12 works fine for me, all unit tests pass on J9. 2006/10/10, Mark Hindess [EMAIL PROTECTED]: On 10 October 2006 at 12:23, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Muahaha... didn't you just say this was something that never changed, was geological in stability, etc, etc? :) :-) Well, yeah, and I was worried until I saw that: a) the change to introduce this variable happened over two years ago, and b) my lucky guess was enough to fix it -Mark. Mark Hindess wrote: On 10 October 2006 at 16:22, Oleg Khaschansky [EMAIL PROTECTED] om wrote: It looks like you don't have lcms.h and, probably, other lcms stuff in Harmony\enhanced\classlib\trunk\depends\libs\build\lcms\. I think the problem is more likely that they do have lcms but that they don't have the same version as everyone else. At a guess, I'd say that the version they are using doesn't have the cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and that: #ifndef cmsFLAGS_NOTCACHE #define cmsFLAGS_NOTCACHE (0) #endif after the #include for lcms.h would solve the problem. But this is a complete guess. -Mark. Recently awt/swing build was enabled by default and it requires this dependency as well as png and jpeg. Read the instructions in Harmony\enhanced\classlib\trunk\depends\libs\build\README.txt. Or check the recent posts about this. E.g. the following recent thread: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: I'm seeing the same problem. Thanks, Pavel On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Got the following compilation error (SLES 9 gcc 3.3.3): build-native: [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/e xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include -I/export/users2/avarlamo/l inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic -Icommon -I../shared//i nclude -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depends / libs/build/lc ms -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTran s form': [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE' undeclared (first use in th is function) [exec] ../shared/cmmxforms.c:150: error: (Each undeclared identifier is reported only on ce [exec] ../shared/cmmxforms.c:150: error: for each function it appear s in.) [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of `cmsSample3DGrid' from incom patible pointer type [exec] make: *** [../shared//cmmxforms.o] Error 1 BUILD FAILED - 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] - 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:
Re: [build] DRLVM build on Windows
Oliver Deakin wrote: This should be listed somewhere under Gotchas while building DRLVM. It would be useful to have these helpful tips stored for future Harmony contributors. I see there are already some useful DRLVM docs on the website - perhaps some kind of build troubleshooting section would also be good? I've started a wiki page DRLVM Build Troubleshooting to collect such recipes. http://wiki.apache.org/harmony/DrlvmBuildTroubleshooting - 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][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target
Mark Hindess wrote: On 11 October 2006 at 3:14, Gregory Shimansky [EMAIL PROTECTED] wrote: On Monday 09 October 2006 19:54 Oliver Deakin wrote: I see that you already said pretty much the same thing I did on another thread [1]. IMHO we should make sure that if the fetch-depends target finds it cannot sym link to preinstalled system libraries, then the user is clearly informed so they have the choice to install them without having the archived file versions unpacked. So perhaps the fetch-depends step should still fail with a message saying something like Could not resolve these dependencies, either build/install these packages manually or you can run this other target to have the archived versions unpacked into your dependency tree. (Hopefully a little clearer than that ;) ) This sounds very much like a configure script. Indeed, and we may well end up with one of those at some point. Check for installed libraries, fail if something is missing. I like it :) I would like to be more helpful if we can. Yesterday, I added the details of the required packages for Fedora Core 5. Hopefully others will help get the instructions up dated for distributions they use. Otherwise, I will try to add instructions for recent SLES and RHEL in the next week or so. Thanks for doing that Mark. On Linux however all libraries are present in distributions (I buy you a beer if you name a single Linux distribution which doesn't include necessary development packages, knoppix not counted). I'll get my better half to start making more room in the fridge while I go through the list of distros at: http://lwn.net/Distributions/ I reckon I should get at least a six-pack just out of the embedded section alone. ;-) Not if I get there first - thanks for the link ;) Only Windows distribution doesn't include them, so for convenience windows binaries may be cached for download on harmony site. In time I expect we'll do the same for others like MacOS X, Aix, etc. Yes, agreed - we should use the system libraries where possible as a first choice, and supply instructions for getting the required packages for those who havnt already got them. For OSes that do not distribute these libraries, we should provide precompiled binaries where possible, or at least some instructions on where to go get them. Regards, Oliver Regards, Mark. - 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]
[drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
GC, VM gurus!
I need your help in implementation of the first our helper written with
magic.
I've started with GCv41 allocation helper for objects.
Please review the way I'm going to implement it and correct me if I have
misunderstood something or confirm if everything is OK.
The native fast path:
Managed_Object_Handle gc_alloc_fast(unsigned in_size, Allocation_Handle ah,
void *thread_pointer) {
C1.assert((in_size % GC_OBJECT_ALIGNMENT) == 0);
C2.assert (ah);
C3.unsigned char *next;
C4.GC_Thread_Info *info = (GC_Thread_Info *) thread_pointer;
C5.Partial_Reveal_VTable *vtable = ah_to_vtable(ah);
C6.GC_VTable_Info *gcvt = vtable-get_gcvt();
C7.unsigned char *cleaned = info-tls_current_cleaned;
C8.unsigned char *res = info-tls_current_free;
C9.if (res + in_size = cleaned) {
C10.if (gcvt-is_finalizible()) return 0;
C11.info-tls_current_free = res + in_size;
C12.*(VT32*)res = ah;
C13.assert(((POINTER_SIZE_INT)res (GC_OBJECT_ALIGNMENT - 1)) ==
0);
C14.return res;
C15.}
C16.if (gcvt-is_finalizible()) return 0;
C17.unsigned char *ceiling = info-tls_current_ceiling;
C18.if (res + in_size = ceiling) {
C19.info-tls_current_free = next = info-tls_current_free +
in_size;
// cleaning required
C20.unsigned char *cleaned_new = next +
THREAD_LOCAL_CLEANED_AREA_SIZE;
C21.if (cleaned_new ceiling) cleaned_new = ceiling;
C22.info-tls_current_cleaned = cleaned_new;
C23.memset(cleaned, 0, cleaned_new - cleaned);
C24.*(VT32*)res = ah;
C25.assert(((POINTER_SIZE_INT)res (GC_OBJECT_ALIGNMENT - 1)) ==
0);
C26.return res;
C27.}
C28.return 0;
}
The helper's code:
public static Object gc_alloc(int objSize, int allocationHandle) {
J1.Address tlsAddr = TLS.getGCThreadLocal();
J2.Address tlsCurrentFreeFieldAddr = tlsAddr.plus
(TLS_CURRENT_FREE_OFFSET);
J3.Address tlsCurrentCleanedFieldAddr = tlsAddr.plus
(TLS_CURRENT_CLEANED_OFFSET);
J4.Address tlsCurrentFreeAddr = tlsCurrentFreeFieldAddr.loadAddress();
J5.Address tlsCurrentCleanedAddr =
tlsCurrentCleanedFieldAddr.loadAddress();
J6.Address tlsNewFreeAddr = tlsCurrentFreeAddr.plus(objSize);
// the fast path without cleaning
J7.if (tlsNewFreeAddr.LE(tlsCurrentCleanedAddr)) {
J8.tlsCurrentFreeFieldAddr.store(tlsNewFreeAddr);
J9.tlsCurrentFreeAddr.store(allocationHandle);
J10.return tlsCurrentFreeAddr;
J11.}
J12.Address tlsCurrentCeilingFieldAddr = tlsAddr.plus
(TLS_CURRENT_CEILING_OFFSET);
J13.Address tlsCurrentCeilingAddr =
tlsCurrentCeilingFieldAddr.loadAddress();
// the fast path with cleaning
J14. if (tlsNewCurrentFreeAddr.LE(tlsCurrentCeilingAddr)) {
J15. Address tlsNewCleanedAddr = tlsCurrentCeilingAddr;
J16. if (tlsCurrentCeilingAddr.diff(tlsNewFreeAddr)
THREAD_LOCAL_CLEANED_AREA_SIZE) {
J17. Address tlsCleanedNew = tlsNewFreeAddr.plus
(THREAD_LOCAL_CLEANED_AREA_SIZE);
J18. }
J19. int bytesToClean = tlsNewCleanedAddr.diff(tlsNewFreeAddr);
J20. org.apache.harmony.vmhelper.native.Utils.memset(tlsNewFreeAddr,
bytesToClean, 0);
J21. tlsCurrentCleanedFieldAddr.store(tlsNewCleanedAddr);
J22. tlsCurrentFreeFieldAddr.store(tlsNewFreeAddr);
J23. tlsCurrentFreeAddr.store(allocationHandle);
J24. return tlsCurrentFreeAddr;
}
//the slow path
//this call will be replaced by JIT with direct native call as VM
magic
org.apache.harmony.vmhelper.native.DRLVMHelper.gc_alloc(objSize,
allocationHandle);
}
The problems I see:
1) The problem: GC helper must know GC_Thread_Info struct offsets.
2) The problem: Where to keep GC magic code? This code is GC specific and
must be available for bootstrap classloader.
JIT can know all the details which magic code to inline (the helper type,
the helper signature) from its properties (see opt.emconf file for example)
3) The problem: Is the signature for gc_alloc method : gc_alloc(int objSize,
int allocationHandle) is universal for all GCs?
I think it's not. But we can extend JIT with different signatures support if
needed.
4) The new magic method is proposed, line J21:
org.apache.harmony.vmhelper.native.Utils.memset(tlsNewFreeAddr,
bytesToClean, 0);
5) The magic code in does not contain 'finalizable' check.
JIT can do this check during the compilation and do not generate the fast
path. This is another option to pass to JIT from GC.
I've enumerated the lines in code if you want to comment it.
Please feel free to review the code and to discuss any other problems I
missed.
--
Mikhail Fursov
Re: [drlvm] Should the launcher print uncaught exceptions?
I have a quick note about detaching current thread. I've filled
HARMONY-1816 issue about counting non daemon threads. And concerning
DetachCurrentThread we should either detach it or rewrite
wait_for_all_nondaemon threads to take into account the fact that main
thread is also non daemon.
Nik.
On 10/11/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Oliver,
I created https://issues.apache.org/jira/browse/HARMONY-1819 with
suggested fix. Please, look at and update it if DetachCurrentThread is
required before DestroyJavaVM for some reason.
Thanks
Evgueni
On 9/22/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 9/22/06, Oliver Deakin [EMAIL PROTECTED] wrote:
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.
Sure, I checked both cases work fine on my implementation of
InvocationAPI for DRLVM (with DetachCurrentThread and without it). So
the launcher can choose either to detach the main thread or not...
Thanks
Evgueni
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
Re: [drlvm][unit tests] the goal is to achieve 100% pass rate
2006/10/11, Elena Semukhina [EMAIL PROTECTED]: Hello all, I think that the goal of running classlib unit tests on DRLVM with 100% pass rate could be worth to achieve. +1 and we will have better pre-commit tests for VM Actually today we have 99% (without awt/swing) but still have about 30 failures/errors. Most of them have been evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki which lists those JIRA issues: http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM I started to look at some of them. Thanks, Mikhail Are there any volunteers to help with DRLVM bugs fixing? 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: [classlib][build] Failed to build classlib on r454714
You probably mean Windows version of lcms. There's the same code for linux and for windows in the lcmm native library, which glues lcms library with awt. As far as I recall, with 1.15 it will compile but fail on the first invocation at runtime (when the color conversion will occur). It wasn't tested with the older versions of lcms also. That's why 1.14 is the best choice. I though I need to install a newer lcms - now I'm happy to live with that. Yes, it compiles, may work and may not. There are no unit tests for the color conversion. No statements on required version for Linux. Right, the readme was modified before the contribution and it seems like this requirement was removed. Nothing changed in the code AFAIK, so 1.14 is still the best choice. I believe that it may compile with other versions (and, probably, that's why the 1.14 requirement was removed) but will it fail at runtime or not is unclear for the older ones. On 10/11/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: Thanks, Alexey! I though I need to install a newer lcms - now I'm happy to live with that. -Pavel On 10/11/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Just to assure that the fix Mark did is good - lcms1.0.12 works fine for me, all unit tests pass on J9. 2006/10/10, Mark Hindess [EMAIL PROTECTED]: On 10 October 2006 at 12:23, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Muahaha... didn't you just say this was something that never changed, was geological in stability, etc, etc? :) :-) Well, yeah, and I was worried until I saw that: a) the change to introduce this variable happened over two years ago, and b) my lucky guess was enough to fix it -Mark. Mark Hindess wrote: On 10 October 2006 at 16:22, Oleg Khaschansky [EMAIL PROTECTED] om wrote: It looks like you don't have lcms.h and, probably, other lcms stuff in Harmony\enhanced\classlib\trunk\depends\libs\build\lcms\. I think the problem is more likely that they do have lcms but that they don't have the same version as everyone else. At a guess, I'd say that the version they are using doesn't have the cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and that: #ifndef cmsFLAGS_NOTCACHE #define cmsFLAGS_NOTCACHE (0) #endif after the #include for lcms.h would solve the problem. But this is a complete guess. -Mark. Recently awt/swing build was enabled by default and it requires this dependency as well as png and jpeg. Read the instructions in Harmony\enhanced\classlib\trunk\depends\libs\build\README.txt. Or check the recent posts about this. E.g. the following recent thread: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: I'm seeing the same problem. Thanks, Pavel On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Got the following compilation error (SLES 9 gcc 3.3.3): build-native: [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/e xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include -I/export/users2/avarlamo/l inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic -Icommon -I../shared//i nclude -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depends / libs/build/lc ms -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTran s form': [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE' undeclared (first use in th is function) [exec] ../shared/cmmxforms.c:150: error: (Each undeclared identifier is reported only on ce [exec] ../shared/cmmxforms.c:150: error: for each function it appear s in.) [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of `cmsSample3DGrid' from incom patible pointer type [exec] make: *** [../shared//cmmxforms.o] Error 1 BUILD FAILED - 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: [build] DRLVM build on Windows
Salikh, I've changed that page a little. According my own experience :) SY, Alexey 2006/10/11, Salikh Zakirov [EMAIL PROTECTED]: Oliver Deakin wrote: This should be listed somewhere under Gotchas while building DRLVM. It would be useful to have these helpful tips stored for future Harmony contributors. I see there are already some useful DRLVM docs on the website - perhaps some kind of build troubleshooting section would also be good? I've started a wiki page DRLVM Build Troubleshooting to collect such recipes. http://wiki.apache.org/harmony/DrlvmBuildTroubleshooting - 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: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest
Hi Alexei I'm sorry I comlpetely don't understand your comment (as well as a number of similar comments in other JIRAs) Thanks, Mikhail 2006/10/7, Alexei Fedotov (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1670?page=comments#action_12440591 ] Alexei Fedotov commented on HARMONY-1670: - [drlvm][unit] Blocks http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM This is a low risk test fix. [classlib][luni] invalid testcase in ClassTest -- Key: HARMONY-1670 URL: http://issues.apache.org/jira/browse/HARMONY-1670 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Trivial Attachments: H-1670.patch The test_getDeclaredMethodLjava_lang_String$Ljava_lang_Class of modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/ClassTest.java checks if IllegalAccessException is thrown during invokation of private method of inner class. This is bad due to: 1) the check is invalid, see HARMONY-1309 for details; 2) The ClassTest is not appropriate for testing reflection, and this is already covered in j.l.reflect.* tests. -- 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]
Re: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest
2006/10/11, Mikhail Loenko [EMAIL PROTECTED]: Hi Alexei I'm sorry I comlpetely don't understand your comment (as well as a number of similar comments in other JIRAs) Hi Mikhail, I'll be happy to clarify. Please tell me which part is not clear? Is it my English or smth else? -- Regards, Alexey Thanks, Mikhail 2006/10/7, Alexei Fedotov (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1670?page=comments#action_12440591 ] Alexei Fedotov commented on HARMONY-1670: - [drlvm][unit] Blocks http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM This is a low risk test fix. [classlib][luni] invalid testcase in ClassTest -- Key: HARMONY-1670 URL: http://issues.apache.org/jira/browse/HARMONY-1670 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Trivial Attachments: H-1670.patch The test_getDeclaredMethodLjava_lang_String$Ljava_lang_Class of modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/ClassTest.java checks if IllegalAccessException is thrown during invokation of private method of inner class. This is bad due to: 1) the check is invalid, see HARMONY-1309 for details; 2) The ClassTest is not appropriate for testing reflection, and this is already covered in j.l.reflect.* tests. -- 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] - 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] Using latest linux snapshot[hdk]...
On 10/11/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 10 October 2006 13:02 Ilya Okomin wrote: On 10/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Yeah, I would have been surprised it that worked. Why not just install v 6? I have libstdc++.so.6 on my system. Nevertheless I have the same results as Dmitry described: bash-2.05b$ ./java -version Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. Failed to open JVM DLL: /work/Harmony/builds/harmony-jre-latest/bin/default/harmonyvm (/lib/ssa/libstdc++.so.6: version `GLIBCXX_3.4' not found (required by /work/Harmony/builds/harmony-jre-latest/bin/default/libharmonyvm.so)) I used harmony-jre-r450941 snapshot. Should I do anything else to resolve this issue? It is probably because your custom libstdc++ is still compiled against an older glibc version of your distribution. Geir uses more modern version. Can you run /lib/libc.so.6 and show the output? You've asked about libc.so.6 output, here it is: GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2.3 20030502 (Red Hat Linux 3.2.3-53). Compiled on a Linux 2.4.20 system on 2005-09-16. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy The C stubs add-on version 2.1.2. BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. I hope this information will clear some questions. Note: everything fine if I use drlvm built from drlvm trunk. Thanks, Ilya. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Ilya Okomin Intel Middleware Products Division
Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable
Gregory Shimansky wrote: On Monday 09 October 2006 21:01 Pavel Pervov wrote: Geir, all, I did reserched this failure some time ago. The same failure was observed on gc.Finalizers. Here is what I've found. Now what is happening: 1) FinalizerThread is being run 2) java/lang/Object.notify()V is being compiled 3) java/lang/InternalError is being resolved (and loaded) for java/lang/Object 4) GC happens while creating instance of java/lang/Class for java/lang/InternalError 5) vm_hint_finalize happens 6) java/lang/ref/ReferenceQueue.enqueue is being called 7) java/lang/Object.notify()V is being compiled 8) java/lang/InternalError is being resolved (and loaded) for java/lang/Object 9) ClassCircularityError occurs for java/lang/InternalError 10) VM returns to step (3) 11) Assertion happens in SuccessLoadingClass for java/lang/InternalError as LoadingClass instance for this class was removed on step (9) It can be tried to fix it in class loading, but I can imagine only one generic solution for this problem: do not run Java while compiling. I believe the real root cause is running java code from vm_hint_finalize(). A possible solution would be: - rewrite vm_hint_finalize() to just run 'notify' operation, without calling any real java code - handle reference queue in the finalizer thread instead of enqueuing it directly from vm_hint_finalize() thread - 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] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest
Mikhail, I already got several personal feedbacks about these comments. I accept that they are not good. I tried to express an idea that JIRAs marked with this comment prevent getting 100% pass rate on DRLVM. When I search for Unit_Tests_Pass_on_DRLVM in comments I will get a list of bugs to fix. Any suggestions how the comment should like? My only requirement is to keep Unit_Tests_Pass_on_DRLVM lexem in this comment. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 2:37 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest Hi Alexei I'm sorry I comlpetely don't understand your comment (as well as a number of similar comments in other JIRAs) Thanks, Mikhail 2006/10/7, Alexei Fedotov (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY- 1670?page=comments#action_12440591 ] Alexei Fedotov commented on HARMONY-1670: - [drlvm][unit] Blocks http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM This is a low risk test fix. [classlib][luni] invalid testcase in ClassTest -- Key: HARMONY-1670 URL: http://issues.apache.org/jira/browse/HARMONY-1670 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Trivial Attachments: H-1670.patch The test_getDeclaredMethodLjava_lang_String$Ljava_lang_Class of modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/Clas sTes t.java checks if IllegalAccessException is thrown during invokation of private method of inner class. This is bad due to: 1) the check is invalid, see HARMONY-1309 for details; 2) The ClassTest is not appropriate for testing reflection, and this is already covered in j.l.reflect.* tests. -- 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] - 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] [tests] Can anyone explain what these are for?
Some tests for beans contained the code like this:
---
public void testGetArguments() {
// Covered in the testcases for the constructor
}
public void testGetMethodName() {
// Covered in the testcases for the constructor
}
---
I just commented it out. I could simply delete it but decided that we
may need it in the future. When we finish with 1.5 and everybody will
have a lot of free time - we can get back to it and think again: do we
need to insert an additional test case here?
Regards,
2006/10/11, Richard Liang [EMAIL PROTECTED]:
On 10/11/06, Nathan Beyer [EMAIL PROTECTED] wrote:
Perhaps, but there are much better ways of determining that. From just
reading the test code to code coverage tools.
From my analysis, these were part of the large test contribution and
indicated that there wasn't an explicit test for that method. In most
cases, there were tests for these methods, either in other classes or
in other methods of the class.
Nathan, I agree ;-)
-Nathan
On 10/10/06, Richard Liang [EMAIL PROTECTED] wrote:
On 10/11/06, Nathan Beyer [EMAIL PROTECTED] wrote:
I've seen a few and I've deleted any that I've come across. I would
say feel free to delete them too. I've also been deleting empty setup
and teardown methods too.
Please do not simply delete them. Maybe that means we are lack of the
test for some methods, for example getInetAddress.
-Nathan
On 10/10/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
These could be a result of copy/paste tests creation.
And I'm curious why it was written for the first time. :)
SY, Alexey
2006/10/10, Mark Hindess [EMAIL PROTECTED]:
I've come across a couple of tests with things like:
public void test_getInetAddress() {
assertTrue(Used to test, true);
}
Can anyone explain why we have these?
--
Alexei Zakharov,
Intel Middleware Product 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: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable
On 10/11/06, Salikh Zakirov [EMAIL PROTECTED] wrote: I believe the real root cause is running java code from vm_hint_finalize(). A possible solution would be: - rewrite vm_hint_finalize() to just run 'notify' operation, without calling any real java code - handle reference queue in the finalizer thread instead of enqueuing it directly from vm_hint_finalize() thread I support the idea to fix the finalization code. The requirement from JIT to use lazy resolution everywhere is overkill in this case. Also the lazy resolution requires very significant changes in the current Jitrino.OPT implementation and will make the static modes (-Xem:opt, -Xem:sever_static) unusable because of the performance degradation. -- Mikhail Fursov
[classlib][launcher]shall we handle the parameter -version and -showversion in launcher or vm?
I encounter an error[1] when run java -version with IBM VME today and it is ok on DRLVM. I wonder how to handle these simple parameters. Is there any decision about that? [1] [EMAIL PROTECTED]:~/harmony/workspace/trunk/deploy/jdk/jre/bin$ ./java -version Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. JVMJ9VM007E Command-line option unrecognised: -version HMYEXEL062E Internal VM error: Failed to create Java VM FAILED to invoke JVM. -- Tony Wu 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] Should the launcher print uncaught exceptions?
Nikolay,
On 10/11/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
I have a quick note about detaching current thread. I've filled
HARMONY-1816 issue about counting non daemon threads. And concerning
DetachCurrentThread we should either detach it
I don't understand your concern what should we detach? Could you
give an example or test case?
or rewrite
wait_for_all_nondaemon threads to take into account the fact that main
thread is also non daemon.
First of all we should not do any assumption regarding main thread. It
doesn't differ from any other non daemon thread. It may die long
before last non daemon thread dies. DestroyJavaVM may be called by any
threadeven unattached...
Thanks Evgueni
Nik.
On 10/11/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Oliver,
I created https://issues.apache.org/jira/browse/HARMONY-1819 with
suggested fix. Please, look at and update it if DetachCurrentThread is
required before DestroyJavaVM for some reason.
Thanks
Evgueni
On 9/22/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 9/22/06, Oliver Deakin [EMAIL PROTECTED] wrote:
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.
Sure, I checked both cases work fine on my implementation of
InvocationAPI for DRLVM (with DetachCurrentThread and without it). So
the launcher can choose either to detach the main thread or not...
Thanks
Evgueni
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!!!);
}
}
Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Mikhail, there is GCVM interface function exists for this purpose:
Boolean gc_supports_frontier_allocation(unsigned *offset_of_current,
unsigned *offset_of_limit) {
// Need additional support for object offset in native stubs.
*offset_of_current = field_offset(GC_Thread_Info, tls_current_free);
*offset_of_limit = field_offset(GC_Thread_Info, tls_current_cleaned);
return true;
}
1. VM exactly knows where the GC_Thread_Info is in TLS and using this
offsets can obtain current allocation position and its limit. It seems
that the information should be also propagated to JIT if you want to
implement the helper inlining.
2. You should not care about cleaned with uncleaned memory as it just
GC v4.1 specific optimization. Fast path should deal with current and
limit as in gc_supports_frontier_allocation().
3. This is just VMGC native interface function. There is no other
parameters passed here currently.
4. No need, see above (in 2).
5. Excellent idea! I thought about it. This optimization can be much valuable.
More issues to deal with.
Current native helper which is called from managed code to allocate a
object has one problem. It should call clinit for uninitialized
classes. I was working with it some time ago, but the change was too
intrusive and had negative performance impact. It was decided to do
this latter. I think we should think about it again now.
I suggest before compiling fast path code check whether class is
initialized and not finalizible. Depending on the results we can
produce different fast (or generic) code paths.
--
Ivan
On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
GC, VM gurus!
I need your help in implementation of the first our helper written with
magic.
I've started with GCv41 allocation helper for objects.
Please review the way I'm going to implement it and correct me if I have
misunderstood something or confirm if everything is OK.
The native fast path:
Managed_Object_Handle gc_alloc_fast(unsigned in_size, Allocation_Handle ah,
void *thread_pointer) {
C1.assert((in_size % GC_OBJECT_ALIGNMENT) == 0);
C2.assert (ah);
C3.unsigned char *next;
C4.GC_Thread_Info *info = (GC_Thread_Info *) thread_pointer;
C5.Partial_Reveal_VTable *vtable = ah_to_vtable(ah);
C6.GC_VTable_Info *gcvt = vtable-get_gcvt();
C7.unsigned char *cleaned = info-tls_current_cleaned;
C8.unsigned char *res = info-tls_current_free;
C9.if (res + in_size = cleaned) {
C10.if (gcvt-is_finalizible()) return 0;
C11.info-tls_current_free = res + in_size;
C12.*(VT32*)res = ah;
C13.assert(((POINTER_SIZE_INT)res (GC_OBJECT_ALIGNMENT - 1)) ==
0);
C14.return res;
C15.}
C16.if (gcvt-is_finalizible()) return 0;
C17.unsigned char *ceiling = info-tls_current_ceiling;
C18.if (res + in_size = ceiling) {
C19.info-tls_current_free = next = info-tls_current_free +
in_size;
// cleaning required
C20.unsigned char *cleaned_new = next +
THREAD_LOCAL_CLEANED_AREA_SIZE;
C21.if (cleaned_new ceiling) cleaned_new = ceiling;
C22.info-tls_current_cleaned = cleaned_new;
C23.memset(cleaned, 0, cleaned_new - cleaned);
C24.*(VT32*)res = ah;
C25.assert(((POINTER_SIZE_INT)res (GC_OBJECT_ALIGNMENT - 1)) ==
0);
C26.return res;
C27.}
C28.return 0;
}
The helper's code:
public static Object gc_alloc(int objSize, int allocationHandle) {
J1.Address tlsAddr = TLS.getGCThreadLocal();
J2.Address tlsCurrentFreeFieldAddr = tlsAddr.plus
(TLS_CURRENT_FREE_OFFSET);
J3.Address tlsCurrentCleanedFieldAddr = tlsAddr.plus
(TLS_CURRENT_CLEANED_OFFSET);
J4.Address tlsCurrentFreeAddr = tlsCurrentFreeFieldAddr.loadAddress();
J5.Address tlsCurrentCleanedAddr =
tlsCurrentCleanedFieldAddr.loadAddress();
J6.Address tlsNewFreeAddr = tlsCurrentFreeAddr.plus(objSize);
// the fast path without cleaning
J7.if (tlsNewFreeAddr.LE(tlsCurrentCleanedAddr)) {
J8.tlsCurrentFreeFieldAddr.store(tlsNewFreeAddr);
J9.tlsCurrentFreeAddr.store(allocationHandle);
J10.return tlsCurrentFreeAddr;
J11.}
J12.Address tlsCurrentCeilingFieldAddr = tlsAddr.plus
(TLS_CURRENT_CEILING_OFFSET);
J13.Address tlsCurrentCeilingAddr =
tlsCurrentCeilingFieldAddr.loadAddress();
// the fast path with cleaning
J14. if (tlsNewCurrentFreeAddr.LE(tlsCurrentCeilingAddr)) {
J15. Address tlsNewCleanedAddr = tlsCurrentCeilingAddr;
J16. if (tlsCurrentCeilingAddr.diff(tlsNewFreeAddr)
THREAD_LOCAL_CLEANED_AREA_SIZE) {
J17. Address tlsCleanedNew = tlsNewFreeAddr.plus
(THREAD_LOCAL_CLEANED_AREA_SIZE);
J18. }
J19. int bytesToClean = tlsNewCleanedAddr.diff(tlsNewFreeAddr);
J20. org.apache.harmony.vmhelper.native.Utils.memset(tlsNewFreeAddr,
bytesToClean, 0);
J21. tlsCurrentCleanedFieldAddr.store(tlsNewCleanedAddr);
J22. tlsCurrentFreeFieldAddr.store(tlsNewFreeAddr);
J23.
Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable
Michail, Generally speaking I can think of fully user code which produces exactly the same result. So, workarounding this in one place (finalizers) just is not enough. Regards, Pavel. On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/11/06, Salikh Zakirov [EMAIL PROTECTED] wrote: I believe the real root cause is running java code from vm_hint_finalize(). A possible solution would be: - rewrite vm_hint_finalize() to just run 'notify' operation, without calling any real java code - handle reference queue in the finalizer thread instead of enqueuing it directly from vm_hint_finalize() thread I support the idea to fix the finalization code. The requirement from JIT to use lazy resolution everywhere is overkill in this case. Also the lazy resolution requires very significant changes in the current Jitrino.OPT implementation and will make the static modes (-Xem:opt, -Xem:sever_static) unusable because of the performance degradation. -- Mikhail Fursov
[wiki] frontpage outdated?
Hi, after creating a wiki page http://wiki.apache.org/harmony/DrlvmBuildTroubleshooting I was wondering where to link it up, so that it would be 'clickable-through' from the start page. I haven't found any suitable place. Moreover, the front page contains a lot of stuff not directly related to the current state of the project. I suggest to clean up front page by moving most of its contents to pages like 'initial project proposals', 'bookmarks' etc. The content which I think is appropriate for the wiki front page are the following links * component links: class library, jchevm, drlvm * status page links * troubleshooting page links It looks like someone already started cleaning and created the page 'OldFrontPage', but the frontpage is still cluttered. Comments? - 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] smoke test : gc PhantomReferenceQueueTest is really unstable
Geir, sorry for confusion. The bug you are referring to is described in [1]. Regards, Pavel. [1] *http://issues.apache.org/jira/browse/HARMONY-1814*http://issues.apache.org/jira/browse/HARMONY-1814 On 10/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I get this more often than not. Can someone interested take a look? Happens w/ jitrino : java: /home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:524: const char* class_get_name(Class*): Assertion `cl' failed. SIGABRT in VM code. Stack trace: addr2line: '[vdso]': No such file 1: ?? (D7^CCA5FEB6A8DCFDA4FFE8E3B6:-1) java: /home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:524: const char* class_get_name(Class*): Assertion `cl' failed. SIGABRT in VM code. Stack trace: addr2line: '[vdso]': No such file 3: ?? (D7^CCA5FEB6B8C8BABFFFE8E3B6:-1) 2: abort (??:-1) 4: __assert_fail (??:-1) 5: abort (??:-1) 6: __assert_fail (??:-1) 7: class_get_name (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:525) 8: class_get_name (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:525) 9: Jitrino::Jet::is_magic(Class*) (??:-1) 10: Jitrino::Jet::Compiler::gen_magic() (??:-1) 11: Jitrino::Jet::Compiler::handle_inst() (??:-1) 12: Jitrino::Jet::is_magic(Class*) (??:-1) 13: Jitrino::Jet::Compiler::gen_magic() (??:-1) 14: Jitrino::Jet::Compiler::handle_inst() (??:-1) 15: Jitrino::Jet::Compiler::comp_gen_insts(unsigned int, unsigned int, unsigned int) (??:-1) 16: Jitrino::Jet::Compiler::comp_gen_code_bb(unsigned int) (??:-1) 17: Jitrino::Jet::Compiler::comp_gen_insts(unsigned int, unsigned int, unsigned int) (??:-1) 18: Jitrino::Jet::Compiler::comp_gen_code_bb(unsigned int) (??:-1) 19: Jitrino::Jet::Compiler::compile(void*, Method*, OpenMethodExecutionParams const) (??:-1) 20: Jitrino::Jet::Compiler::compile(void*, Method*, OpenMethodExecutionParams const) (??:-1) 21: Jitrino::Jet::compile_with_params(void*, void*, Method*, OpenMethodExecutionParams) (??:-1) 22: Jitrino::Jet::compile_with_params(void*, void*, Method*, OpenMethodExecutionParams) (??:-1) 23: JIT_compile_method_with_params (??:-1) 24: JIT_compile_method_with_params (??:-1) 25: Dll_JIT::compile_method_with_params(void*, Method*, OpenMethodExecutionParams) (/home/geir/dev/apache/harmony/enhanced/trunk/working_v m/vm/vmcore/include/dll_jit_intf.h:86) 26: compile_do_compilation_jit(Method*, JIT*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:700) 27: vm_compile_method (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:2539) 28: Dll_JIT::compile_method_with_params(void*, Method*, OpenMethodExecutionParams) (/home/geir/dev/apache/harmony/enhanced/trunk/working_v m/vm/vmcore/include/dll_jit_intf.h:86) 29: compile_do_compilation_jit(Method*, JIT*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:700) 30: vm_compile_method (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:2539) 31: DrlEMImpl::compileMethod(Method*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/em/src/DrlEMImpl.cpp:520) 32: CompileMethod (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/em/src/em_intf.cpp:50) 33: compile_do_compilation (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:780) 34: compile_jit_a_method(Method*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:828) 35: IP is 0xB6891172 native code 36: java/lang/FinalizerThread.wakeupFinalization()V (??:-1) 37: java/lang/FinalizerThread.startFinalization(Z)V (??:-1) 38: vm_invoke_native_array_stub (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/util/ia32/base/invoke_native_stub_i a32.asm:41) 39: JIT_execute_method_default(void*, _jmethodID*, jvalue*, jvalue*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/sr c/util/ia32/base/ini_iA32.cpp:200) 40: DrlEMImpl::compileMethod(Method*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/em/src/DrlEMImpl.cpp:520) 41: CompileMethod (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/em/src/em_intf.cpp:50) 42: compile_do_compilation (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:780) 43: compile_jit_a_method(Method*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:828) 44: IP is
Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable
Pavel, Can you describe the problem with user's code only? Would BEA or SUN VM be able to run the test? I think we can create a separate discussion or JIRA for it. On 10/11/06, Pavel Pervov [EMAIL PROTECTED] wrote: Michail, Generally speaking I can think of fully user code which produces exactly the same result. So, workarounding this in one place (finalizers) just is not enough. Regards, Pavel. On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/11/06, Salikh Zakirov [EMAIL PROTECTED] wrote: I believe the real root cause is running java code from vm_hint_finalize(). A possible solution would be: - rewrite vm_hint_finalize() to just run 'notify' operation, without calling any real java code - handle reference queue in the finalizer thread instead of enqueuing it directly from vm_hint_finalize() thread I support the idea to fix the finalization code. The requirement from JIT to use lazy resolution everywhere is overkill in this case. Also the lazy resolution requires very significant changes in the current Jitrino.OPT implementation and will make the static modes (-Xem:opt, -Xem:sever_static) unusable because of the performance degradation. -- Mikhail Fursov -- Mikhail Fursov
Re: [drlvm] Should the launcher print uncaught exceptions?
Evgueni, On 10/11/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: I have a quick note about detaching current thread. I've filled HARMONY-1816 issue about counting non daemon threads. And concerning DetachCurrentThread we should either detach it I don't understand your concern what should we detach? Could you give an example or test case? HARMONY-1816 contains such a test case, it hangs because child thread works a bit longer than main method. In this case main method exits, but the main thread enters wait for all non daemon treads method. It checks that non daemon count 1, 1 stands for itself and enters while cycle with condition that non-daemon threads should be equal to zero, while the main thread also non-daemon. or rewrite wait_for_all_nondaemon threads to take into account the fact that main thread is also non daemon. First of all we should not do any assumption regarding main thread. It doesn't differ from any other non daemon thread. It may die long before last non daemon thread dies. DestroyJavaVM may be called by any threadeven unattached... I agree, but the thread which counts non-daemon threads should take into account that it itself may also daemon or non-daemon and count other threads till 1 or 0 or detach(or countdown non-daemon threads) itself before waiting. Nik. Thanks Evgueni Nik. On 10/11/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Oliver, I created https://issues.apache.org/jira/browse/HARMONY-1819 with suggested fix. Please, look at and update it if DetachCurrentThread is required before DestroyJavaVM for some reason. Thanks Evgueni On 9/22/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/22/06, Oliver Deakin [EMAIL PROTECTED] wrote: 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. Sure, I checked both cases work fine on my implementation of InvocationAPI for DRLVM (with DetachCurrentThread and without it). So the launcher can choose either to detach the main thread or not... Thanks Evgueni 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
RE: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Folks, I took a close look at the README file and Quick Help pages for users [1] and developers [2] and created patches for these three docs [JIRA 1730] https://issues.apache.org/jira/browse/HARMONY-1730 Taking into consideration latest changes, I fixed duplication of info and out-dated content, and tried to improve language in some places. It would be great if someone can find a chance to look at the patches. Your feedback is very important! Thanks in advance! [1] http://incubator.apache.org/harmony/quickhelp_users.html [2] http://incubator.apache.org/harmony/quickhelp_contributors.html Cheers, Sveta Konovalova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, October 06, 2006 1:18 PM To: harmony-dev@incubator.apache.org Subject: Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 I was looking at the patch, and think we should just chuck the whole README.txt, salvage what's good, put it on the website, and put a pointer in the README.txt to the website. geir Morozova, Nadezhda wrote: Thanks for the fix, Alexei. I think this is a good start for updating the README. I've looked at the current version, and many other things are out-of-date (such as ij as the name of our executable). Some things are also duplicated - we now have the nice Quick Help pages for users [1] and developers [2]. As I see it, the Quick Start you've been referring to roughly matches [1], whereas [2] is for those who have to 'read this README and follow building instructions to the point.' :) I suggest that we edit the README file more to improve it. What do you think? Do you think we can use JIRA 1730 for these changes? [1] http://incubator.apache.org/harmony/quickhelp_users.html [2] http://incubator.apache.org/harmony/quickhelp_contributors.html Best regards, Nadya Morozova -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:23 AM To: Morozova, Nadezhda Cc: harmony-dev@incubator.apache.org Subject: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 BTW, I really enjoyed the last item of the Quick Start section: 7. If building the DRLVM fails, read this README and follow building instructions to the point. A hardcore programmer can loop infinitely here. :-) With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:20 AM To: =SMTP:[EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Hi, Nadya, I tried to build DRLVM, faced the issue from the thread below, and filed a JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1730. Does the patch worth to be applied to the README.txt? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Spark Shen [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 9:56 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Thank you, I am trying :-). 2006/9/22, Vladimir Gorr [EMAIL PROTECTED]: On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: 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. It seems you didn't run the *build.bat update* before starting the build. We need to run the following steps (sorry if you're aware about this): - svn checkout classlib - svn checkout drlvm - build classlib (cd classlib/trunk; ant fetch-depend; ant) - cd drlvm/trunk/build - build.bat update (you need to slightly some time here :-) ) - build.bat Thanks, Vladimir. [1]
Re: [drlvm] Should the launcher print uncaught exceptions?
Nikolay, From what you said above I conclude that it is TM problem in respect to how it manages non-daemon threads. Do you agree? If you don't please start another thread with appropriate subject. It seems to be out of current topic. Evgueni On 10/11/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Evgueni, On 10/11/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: I have a quick note about detaching current thread. I've filled HARMONY-1816 issue about counting non daemon threads. And concerning DetachCurrentThread we should either detach it I don't understand your concern what should we detach? Could you give an example or test case? HARMONY-1816 contains such a test case, it hangs because child thread works a bit longer than main method. In this case main method exits, but the main thread enters wait for all non daemon treads method. It checks that non daemon count 1, 1 stands for itself and enters while cycle with condition that non-daemon threads should be equal to zero, while the main thread also non-daemon. or rewrite wait_for_all_nondaemon threads to take into account the fact that main thread is also non daemon. First of all we should not do any assumption regarding main thread. It doesn't differ from any other non daemon thread. It may die long before last non daemon thread dies. DestroyJavaVM may be called by any threadeven unattached... I agree, but the thread which counts non-daemon threads should take into account that it itself may also daemon or non-daemon and count other threads till 1 or 0 or detach(or countdown non-daemon threads) itself before waiting. Nik. Thanks Evgueni Nik. On 10/11/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Oliver, I created https://issues.apache.org/jira/browse/HARMONY-1819 with suggested fix. Please, look at and update it if DetachCurrentThread is required before DestroyJavaVM for some reason. Thanks Evgueni On 9/22/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/22/06, Oliver Deakin [EMAIL PROTECTED] wrote: 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. Sure, I checked both cases work fine on my implementation of InvocationAPI for DRLVM (with DetachCurrentThread and without it). So the launcher can choose either to detach the main thread or not... Thanks Evgueni 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
Re: [wiki] frontpage outdated?
Salikh, I thought that you have problems with MS software when read the subject :) + I support your idea and the only item I want to add is to avoid duplication in wiki and main project pages. This will simplify maintenance. So instead of any news/status information in wiki we should keep only links to non-wiki pages. And do the same (avoid duplication) for internal information for all of the components we have. On 10/11/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Hi, after creating a wiki page http://wiki.apache.org/harmony/DrlvmBuildTroubleshooting I was wondering where to link it up, so that it would be 'clickable-through' from the start page. I haven't found any suitable place. Moreover, the front page contains a lot of stuff not directly related to the current state of the project. I suggest to clean up front page by moving most of its contents to pages like 'initial project proposals', 'bookmarks' etc. The content which I think is appropriate for the wiki front page are the following links * component links: class library, jchevm, drlvm * status page links * troubleshooting page links It looks like someone already started cleaning and created the page 'OldFrontPage', but the frontpage is still cluttered. Comments? - 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
[dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
(Branching from original thread as this is different problem than in the root message.) Mikhail, The following scenario will fail: 1) JIT compiles some method and resolves some class A through user defined class loader 2) user define class loader loads class A and triggers compilation of some of its methods 3) this method happens to depend on class A, and, thus, JIT resolves the class A through the same class loader Voila! We have the described situation. Regards, Pavel. On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Pavel, Can you describe the problem with user's code only? Would BEA or SUN VM be able to run the test? I think we can create a separate discussion or JIRA for it. On 10/11/06, Pavel Pervov [EMAIL PROTECTED] wrote: Michail, Generally speaking I can think of fully user code which produces exactly the same result. So, workarounding this in one place (finalizers) just is not enough. Regards, Pavel. On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/11/06, Salikh Zakirov [EMAIL PROTECTED] wrote: I believe the real root cause is running java code from vm_hint_finalize(). A possible solution would be: - rewrite vm_hint_finalize() to just run 'notify' operation, without calling any real java code - handle reference queue in the finalizer thread instead of enqueuing it directly from vm_hint_finalize() thread I support the idea to fix the finalization code. The requirement from JIT to use lazy resolution everywhere is overkill in this case. Also the lazy resolution requires very significant changes in the current Jitrino.OPT implementation and will make the static modes (-Xem:opt, -Xem:sever_static) unusable because of the performance degradation. -- Mikhail Fursov -- Mikhail Fursov
[classlib][em64t]Problems during classlib on em64t (revision 462753)
Hi, I've tried to build classlib on em64t workstation an got some problems: 0. Bug in depends.xml - hosts architectures defined with bug --- condition property=hack.arch value=ipf isset property=is.x86_64 / /condition --- small fix condition property=hack.arch value=ia64 isset property=is.ia64 / /condition condition property=hack.arch value=x86_64 isset property=is.x86_64 / /condition --- 1. ant (1.6.5 or 1.7.0.beta2 - I've tried to use both) cannot create symlinks. It is not serious porblem - it is possible to create these lintks manually 2. build process was interrupted by error: -- -really-link: check: -compile: [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build/classes [javac] Compiling 3397 source files to /home/angel/builds/harmony/suse- 10.1-em64t/clean/classlib/trunk/build/classes [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/deploy/jdk/jre/lib/boot call-modules-all: compile-java: [echo] Compiling ACCESSIBILITY classes copy-resources: [copy] Copying 1 file to /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build/classes svn-info: build-jar: BUILD FAILED /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/build.xml:108: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/build- java.xml:183: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properties.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properties.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/modules/accessibility/build.xml:90: No supported regular expression ma tcher found Total time: 56 seconds Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 14:36:02 $ -- It seems as an ant bug. Could someone help me?
[classlib][luni] Tweaked native method name in file
Hi All: After skimming through the source code of java.io.File, I found two tweaked method names: private native boolean isReadOnlyImpl(byte[] filePath); private native boolean isWriteOnlyImpl(byte[] filePath); Take isWriteOnlyImpl as an example, canRead - exists !Java_java_io_File_isWriteOnlyImpl() - = this method is in native\luni\shared\file.c getPlatformIsWriteOnly() = this method is in native\luni\linux\helpers.c, and the follow is the code snippet if (buffer.st_uid == geteuid ()) return (buffer.st_mode S_IRUSR) == 0; else if (buffer.st_gid == getegid ()) return (buffer.st_mode S_IRGRP) == 0; return (buffer.st_mode S_IROTH) == 0; The name isWriteOnlyImpl is confusing, negate the return value of isWriteOnlyImpl and uses it in canRead is confusing, in native method getPlatformIsWriteOnly(), prob S_IRXXX bit is also confusing and can not express the meaning writeOnly. Correct me if I am wrong. Since isWriteOnlyImpl is only utilized by canRead, I suggest the following: change isWriteOnlyImpl to isReadableImpl, getPlatformIsWriteOnly to getPlatformIsReadable and do the negation in getPlatformIsReadable: canRead - exists Java_java_io_File_isReadOnlyImpl() - getPlatformIsReadable() if (buffer.st_uid == geteuid ()) return (buffer.st_mode S_IRUSR) != 0; else if (buffer.st_gid == getegid ()) return (buffer.st_mode S_IRGRP) != 0; return (buffer.st_mode S_IROTH) != 0; This way, code is more readable and the method name getPlatformIsReadable semantically matches it implemantation. (The original name getPlatformIsWriteOnly seems not consistent with its implmentation, correct me if I am wrong). If no one objects, I want to supply a patch to do the enhancement. 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: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Ivan,
On 10/11/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Mikhail, there is GCVM interface function exists for this purpose:
Boolean gc_supports_frontier_allocation(unsigned *offset_of_current,
unsigned *offset_of_limit) {
// Need additional support for object offset in native stubs.
*offset_of_current = field_offset(GC_Thread_Info, tls_current_free);
*offset_of_limit = field_offset(GC_Thread_Info, tls_current_cleaned);
return true;
}
Yes, I know. But the main benefit of magics is that JIT does not know the
details of the allocation algorithm.
The helper is a GC part. You, or any other GC developer, can write any
fast-path helper you like and point the JIT to use it.
So my proposal is to use known offset in GC_Thread_Info and hardcode it into
the helper code.
Another solution is to initialize these offsets as final static fields
during helper class initialization using JNI accessor to GC natives.
1. VM exactly knows where the GC_Thread_Info is in TLS and using this
offsets can obtain current allocation position and its limit. It seems
that the information should be also propagated to JIT if you want to
implement the helper inlining.
Yes, this is not the problem. In the example I wrote the
TLS.getGCThreadLocal() does the same.
2. You should not care about cleaned with uncleaned memory as it just
GC v4.1 specific optimization. Fast path should deal with current and
limit as in gc_supports_frontier_allocation().
This is the helper for GCv4.1. JIT does not care if memory cleaned or not.
JIT does not care if you use bump-pointer of free-list allocation. So it's
up to you if too keep it.
3. This is just VMGC native interface function. There is no other
parameters passed here currently.
Yes, it's enough to support GCv4.x and GCv5. But is it OK for MMTK
collectors? The main idea is to make JIT as independent as possible.
4. No need, see above (in 2).
Ok, if you do not need this functionality in the fast path we can remove it.
5. Excellent idea! I thought about it. This optimization can be much
valuable.
More issues to deal with.
Current native helper which is called from managed code to allocate a
object has one problem. It should call clinit for uninitialized
classes. I was working with it some time ago, but the change was too
intrusive and had negative performance impact. It was decided to do
this latter. I think we should think about it again now.
I thought that the problem is already solved on the JIT side?!
That was a real headache for me to synchronize check sums and map edge
profiles from the IR with class initialization helpers to IR without it in
server mode.
I suggest before compiling fast path code check whether class is
initialized and not finalizible. Depending on the results we can
produce different fast (or generic) code paths.
Finalization issue is clean. But I see no improvements in the fast path
related to the class initialization.
--
Mikhail Fursov
Re: [drlvm] Should the launcher print uncaught exceptions?
Sorry guys, I've just found different problem at the very same place. Nik. On 10/11/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Nikolay, From what you said above I conclude that it is TM problem in respect to how it manages non-daemon threads. Do you agree? If you don't please start another thread with appropriate subject. It seems to be out of current topic. Evgueni On 10/11/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Evgueni, On 10/11/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: I have a quick note about detaching current thread. I've filled HARMONY-1816 issue about counting non daemon threads. And concerning DetachCurrentThread we should either detach it I don't understand your concern what should we detach? Could you give an example or test case? HARMONY-1816 contains such a test case, it hangs because child thread works a bit longer than main method. In this case main method exits, but the main thread enters wait for all non daemon treads method. It checks that non daemon count 1, 1 stands for itself and enters while cycle with condition that non-daemon threads should be equal to zero, while the main thread also non-daemon. or rewrite wait_for_all_nondaemon threads to take into account the fact that main thread is also non daemon. First of all we should not do any assumption regarding main thread. It doesn't differ from any other non daemon thread. It may die long before last non daemon thread dies. DestroyJavaVM may be called by any threadeven unattached... I agree, but the thread which counts non-daemon threads should take into account that it itself may also daemon or non-daemon and count other threads till 1 or 0 or detach(or countdown non-daemon threads) itself before waiting. Nik. Thanks Evgueni Nik. On 10/11/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Oliver, I created https://issues.apache.org/jira/browse/HARMONY-1819 with suggested fix. Please, look at and update it if DetachCurrentThread is required before DestroyJavaVM for some reason. Thanks Evgueni On 9/22/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/22/06, Oliver Deakin [EMAIL PROTECTED] wrote: 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. Sure, I checked both cases work fine on my implementation of InvocationAPI for DRLVM (with DetachCurrentThread and without it). So the launcher can choose either to detach the main thread or not... Thanks Evgueni 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
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Will this test pass on SUN or BEA JVM? I remember I tried something similar but one of the RIs crashed :) On 10/11/06, Pavel Pervov [EMAIL PROTECTED] wrote: (Branching from original thread as this is different problem than in the root message.) Mikhail, The following scenario will fail: 1) JIT compiles some method and resolves some class A through user defined class loader 2) user define class loader loads class A and triggers compilation of some of its methods 3) this method happens to depend on class A, and, thus, JIT resolves the class A through the same class loader Voila! We have the described situation. Regards, Pavel. -- Mikhail Fursov
Re: [classlib][regex|luni] build break
On 10/10/06, Anton Ivanov [EMAIL PROTECTED] wrote:
On 10/10/06, Tim Ellison [EMAIL PROTECTED] wrote:
So I checked in a patch for HARMONY-688's regex fix, and it passed the
regex unit tests, but causes the existing luni tests to fail in
java.util.Scanner. I've not figured out the base cause of the failure
so I've backed out the changes.
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]
This is my patch.
I'll look into this problem and try to correct the patch.
Thanks,
Anton
There was a bug in the newly created class SupplRangeSet.java.
There was the following code in the method matches() of SupplRangeSet.java:
...
if (stringIndex strLength) {
char high = testString.charAt(stringIndex++);
if (contains(high)
next.matches(stringIndex, testString, matchResult) 0)
{
return 1;
}
...
But it is wrong simply to return 1, though we can read about method
matches() in AbstractSet.java comments:
Checks if this node matches in given position and recursively call
next node matches on positive self match. Returns positive integer if
entire match succeed, negative otherwise
return -1 if match fails or n 0;
In fact method matches() returns not only a positive n 0. The n is an
offset in case of a positive
match attempt. This fact is took into account in all old classes of
java.util.regex, but I forgot this fact in SupplRangeSet.java
So I corrected method matches() of the SupplRangeSet class as follows:
...
int offset = -1;
if (stringIndex strLength) {
char high = testString.charAt(stringIndex++);
if (contains(high)
(offset = next.matches(stringIndex, testString,
matchResult)) 0) {
return offset;
}
...
I corrected the patch and attached it to the issue.
I verified that regex and luni tests pass normally with the patch applied.
Thanks,
Anton
Re: [drlvm][jvmti] Last commit of Harmony-1582 brocks JVMTI support for DRLVM.
The fix is ready. See http://issues.apache.org/jira/browse/HARMONY-1826 On 10/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Pavel Rebriy wrote: Hello, Fix for Harmony-1582 brocks initialization of JVMTI support. I'm investigating the problem and going to create fixing JIRA as soon as possible. Great - thanks P.S. May be include several JVMTI tests into build test. Yes, please do. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy
Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Ivan,
On 10/11/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Mikhail, there is GCVM interface function exists for this purpose:
Boolean gc_supports_frontier_allocation(unsigned *offset_of_current,
unsigned *offset_of_limit) {
// Need additional support for object offset in native stubs.
*offset_of_current = field_offset(GC_Thread_Info, tls_current_free);
*offset_of_limit = field_offset(GC_Thread_Info, tls_current_cleaned);
return true;
}
Yes, I know. But the main benefit of magics is that JIT does not know the
details of the allocation algorithm.
The helper is a GC part. You, or any other GC developer, can write any
fast-path helper you like and point the JIT to use it.
So my proposal is to use known offset in GC_Thread_Info and hardcode it into
the helper code.
Another solution is to initialize these offsets as final static fields
during helper class initialization using JNI accessor to GC natives.
Ahh, I see now. I was thinking about GC independent helper. You are right.
1. VM exactly knows where the GC_Thread_Info is in TLS and using this
offsets can obtain current allocation position and its limit. It seems
that the information should be also propagated to JIT if you want to
implement the helper inlining.
Yes, this is not the problem. In the example I wrote the
TLS.getGCThreadLocal() does the same.
ok
2. You should not care about cleaned with uncleaned memory as it just
GC v4.1 specific optimization. Fast path should deal with current and
limit as in gc_supports_frontier_allocation().
This is the helper for GCv4.1. JIT does not care if memory cleaned or not.
JIT does not care if you use bump-pointer of free-list allocation. So it's
up to you if too keep it.
ok
3. This is just VMGC native interface function. There is no other
parameters passed here currently.
Yes, it's enough to support GCv4.x and GCv5. But is it OK for MMTK
collectors? The main idea is to make JIT as independent as possible.
Let's ask Weldon here.
4. No need, see above (in 2).
Ok, if you do not need this functionality in the fast path we can remove it.
Well, if we talk about GC specific helpers, I would prefer to keep it :)
5. Excellent idea! I thought about it. This optimization can be much
valuable.
More issues to deal with.
Current native helper which is called from managed code to allocate a
object has one problem. It should call clinit for uninitialized
classes. I was working with it some time ago, but the change was too
intrusive and had negative performance impact. It was decided to do
this latter. I think we should think about it again now.
I thought that the problem is already solved on the JIT side?!
That was a real headache for me to synchronize check sums and map edge
profiles from the IR with class initialization helpers to IR without it in
server mode.
It is possible that I have outdated information.
I suggest before compiling fast path code check whether class is
initialized and not finalizible. Depending on the results we can
produce different fast (or generic) code paths.
Finalization issue is clean. But I see no improvements in the fast path
related to the class initialization.
If we still has issues with initialization we could do the following:
1. If class in already initialized when we compile the allocation code
we can forget about the initialization.
2. If it is not initialized yet, we can insert required initialization
check right before usual allocation fast path.
--
Mikhail Fursov
--
Ivan
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: HARMONY-1407: Contribution of Java code for package java.lang.management
Why not write LogManager.getLoggingMXBean like this:
return com.ibm.lang.management.ManagementUtils.getLoggingBean();
Yes, it also possible, but tightly binds logging module to
lang-managment implementation.
I found the problem about StackTraceElement when I used luni-kernel.jar
(in jre/bin/default) in build-path of project, it could not compile; and
when I replaced it with luni-kernel-stubs.jar (in jre/lib/boot), it was
OK. Maybe your problem is not exactly as mine.
Yes, you are right. Deeper investigation showed that problem was in
CompositeDataSupport constructor and exists not only for
StackTraceElement class. This is minimal test that fails on DRLVM but
works well on J9:
---8--
import javax.management.openmbean.*;
class CompositeDataTest {
public static void main(String[] args) throws Exception {
String[] names = { goodName };
OpenType[] te = { SimpleType.STRING };
CompositeType ct = new CompositeType(goodName, goodName,
names, names, te);
CompositeData[] cda = { new CompositeDataSupport(ct, names, names) };
Object[] values = { cda };
OpenType[] typeTypes = { new ArrayType(1, ct) };
CompositeType ct2 = new CompositeType(goodName, goodName,
names, names, typeTypes);
new CompositeDataSupport(ct2, names, values);
System.out.println(Passed);
}
}
---8-
I think the vote is coming, we'd best move on after voting, :-)
It's a pity but I've already created
http://issues.apache.org/jira/browse/HARMONY-1821 :-)
Thanks,
Andrey
On 10/11/06, Rui Hu [EMAIL PROTECTED] wrote:
On 10/5/06, Andrey Yakushev [EMAIL PROTECTED] wrote:
I've tried to follow you suggestions. The result:
1. The fix for unimplemented
java.util.logging.LogManager.getLoggingMXBean could be simple, like:
return LoggingMXBeanImpl.getInstance()
But it bind logging module to LoggingMXBean implementation.
Probably more clean solution would be:
ObjectName loggingMXBeanName = new
ObjectName(LOGGING_MXBEAN_NAME);
MBeanServer platformBeanServer =
ManagementFactory.getPlatformMBeanServer();
Set loggingMXBeanSet =
platformBeanServer.queryMBeans(loggingMXBeanName, null);
if(loggingMXBeanSet.size() != 1) {
throw new AssertionError(There Can Be Only One
logging MX bean.);
}
Iterator i = loggingMXBeanSet.iterator();
ObjectInstance loggingMXBeanOI = (ObjectInstance) i.next();
String lmxbcn = loggingMXBeanOI.getClassName();
Class lmxbc = Class.forName(lmxbcn);
Method giMethod = lmxbc.getDeclaredMethod(getInstance);
giMethod.setAccessible(true);
LoggingMXBean lmxb = (LoggingMXBean) giMethod.invoke(null,
new Object[] {});
return lmxb;
But this approach also supposes that implementation contains
getInstance method, which is not always true as far as I know.
Probably some other solution exists?
Sorry for reply so late.
Why not write LogManager.getLoggingMXBean like this:
return com.ibm.lang.management.ManagementUtils.getLoggingBean();
The similar implementation can be found in some public methods in
java.lang.management.ManagementFactory
2. One more problem fount is that
\management\src\main\java\org\apache\harmony\lang\management\CompilationMXBeanImpl.java
uses System.getProperty(java.compiler) which is not defined and it
lead to NullPointerException in
testGetAttribute(
tests.org.apache.harmony.lang.management.CompilationMXBeanImplTest)
Running tests with -Djava.compiler=jitrino removes this test error.
It is interest that test_getProperty_Str from
inincubator\harmony\enhanced\drlvm\trunk\vm\tests\kernel\java\lang\SystemExtensionTest
tries to check that but couldn't due to error in test (using ||
instead of ).
3. As to StackTraceElement problem, I obtain the fail:
javax.management.openmbean.OpenDataException: itemValue at index 12 is
not a valid value for itemName stackTrace and itemType
javax.management.openmbean.CompositeData(typename=[
Ljavax.management.openmbean.CompositeData;,dimension=1,elementType=
javax.management.openmbean.CompositeData
TypeName: java.lang.StackTraceElement contains data:
ItemName: className OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: fileName OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: lineNumber OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.Integer)
ItemName: methodName OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: nativeMethod OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.Boolean)
)
at javax.management.openmbean.CompositeDataSupport.validateContents
(CompositeDataSupport.java:104)
at
Re: [classlib][em64t]Problems during classlib on em64t (revision 462753)
On 11 October 2006 at 16:18, Valentin Al. Sitnick (Moscow) [EMAIL PROTECTED] wrote: Hi, I've tried to build classlib on em64t workstation an got some problems: 0. Bug in depends.xml - hosts architectures defined with bug --- condition property=hack.arch value=ipf isset property=is.x86_64 / /condition --- small fix condition property=hack.arch value=ia64 isset property=is.ia64 / /condition condition property=hack.arch value=x86_64 isset property=is.x86_64 / /condition --- 1. ant (1.6.5 or 1.7.0.beta2 - I've tried to use both) cannot create symlinks. It is not serious porblem - it is possible to create these lintks manually 2. build process was interrupted by error: - - -really-link: check: -compile: [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build/classes [javac] Compiling 3397 source files to /home/angel/builds/harmony/suse- 10.1-em64t/clean/classlib/trunk/build/classes [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/deploy/jdk/jre/lib/boot call-modules-all: compile-java: [echo] Compiling ACCESSIBILITY classes copy-resources: [copy] Copying 1 file to /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build/classes svn-info: build-jar: BUILD FAILED /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/build.xml:108 : The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/build- java.xml:183: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properti es.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properti es.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/modules/acces sibility/build.xml:90: No supported regular expression ma tcher found Total time: 56 seconds Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 14:36:02 $ - - It seems as an ant bug. Could someone help me? I've never seen this error, but it looks like you are missing a regex implementation. The ant regexp glob mapper has some dependencies described at: http://ant.apache.org/manual/CoreTypes/mapper.html#regexp-mapper But basically it says you need: Ant comes with implementations for the java.util.regex package of JDK 1.4 or higher, jakarta-regexp and jakarta-ORO. I'm kind of surprised you don't have the first of these? Regards, Mark. - 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] Tweaked native method name in file
On 10/11/06, Spark Shen [EMAIL PROTECTED] wrote: Hi All: After skimming through the source code of java.io.File, I found two tweaked method names: private native boolean isReadOnlyImpl(byte[] filePath); private native boolean isWriteOnlyImpl(byte[] filePath); Take isWriteOnlyImpl as an example, canRead - exists !Java_java_io_File_isWriteOnlyImpl() - = this method is in native\luni\shared\file.c getPlatformIsWriteOnly() = this method is in native\luni\linux\helpers.c, and the follow is the code snippet if (buffer.st_uid == geteuid ()) return (buffer.st_mode S_IRUSR) == 0; else if (buffer.st_gid == getegid ()) return (buffer.st_mode S_IRGRP) == 0; return (buffer.st_mode S_IROTH) == 0; The name isWriteOnlyImpl is confusing, negate the return value of isWriteOnlyImpl and uses it in canRead is confusing, in native method getPlatformIsWriteOnly(), prob S_IRXXX bit is also confusing and can not express the meaning writeOnly. Correct me if I am wrong. Since isWriteOnlyImpl is only utilized by canRead, I suggest the following: change isWriteOnlyImpl to isReadableImpl, getPlatformIsWriteOnly to getPlatformIsReadable and do the negation in getPlatformIsReadable: Agree. But I don't think it's negation. you may simplify the code as: if (buffer.st_uid == geteuid ()) return buffer.st_mode S_IRUSR; ... canRead - exists Java_java_io_File_isReadOnlyImpl() - getPlatformIsReadable() if (buffer.st_uid == geteuid ()) return (buffer.st_mode S_IRUSR) != 0; else if (buffer.st_gid == getegid ()) return (buffer.st_mode S_IRGRP) != 0; return (buffer.st_mode S_IROTH) != 0; This way, code is more readable and the method name getPlatformIsReadable semantically matches it implemantation. (The original name getPlatformIsWriteOnly seems not consistent with its implmentation, correct me if I am wrong). Agree. I think we'd better fix it, although it's only an internal method. If no one objects, I want to supply a patch to do the enhancement. 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] -- Best regards, Andrew Zhang
Re: [classlib][launcher]shall we handle the parameter -version and -showversion in launcher or vm?
This issue was discussed several times already. Seems that the set of 'standard' options should be defined for Harmony VM's and describe somewhere. But nobody do it yet :) thanks, Vladimir On 10/11/06, Tony Wu [EMAIL PROTECTED] wrote: I encounter an error[1] when run java -version with IBM VME today and it is ok on DRLVM. I wonder how to handle these simple parameters. Is there any decision about that? [1] [EMAIL PROTECTED]:~/harmony/workspace/trunk/deploy/jdk/jre/bin$ ./java -version Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. JVMJ9VM007E Command-line option unrecognised: -version HMYEXEL062E Internal VM error: Failed to create Java VM FAILED to invoke JVM. -- Tony Wu 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][em64t]Problems during classlib on em64t (revision 462753)
Hi Mark, I have - sun JDK-1.5.0 64 bit version - ant 1.6.5 1.7.0b2 On 10/11/06, Mark Hindess [EMAIL PROTECTED] wrote: On 11 October 2006 at 16:18, Valentin Al. Sitnick (Moscow) [EMAIL PROTECTED] wrote: Hi, I've tried to build classlib on em64t workstation an got some problems: 0. Bug in depends.xml - hosts architectures defined with bug --- condition property=hack.arch value=ipf isset property=is.x86_64 / /condition --- small fix condition property=hack.arch value=ia64 isset property=is.ia64 / /condition condition property=hack.arch value=x86_64 isset property=is.x86_64 / /condition --- 1. ant (1.6.5 or 1.7.0.beta2 - I've tried to use both) cannot create symlinks. It is not serious porblem - it is possible to create these lintks manually 2. build process was interrupted by error: - - -really-link: check: -compile: [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build/classes [javac] Compiling 3397 source files to /home/angel/builds/harmony/suse- 10.1-em64t/clean/classlib/trunk/build/classes [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/deploy/jdk/jre/lib/boot call-modules-all: compile-java: [echo] Compiling ACCESSIBILITY classes copy-resources: [copy] Copying 1 file to /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build/classes svn-info: build-jar: BUILD FAILED /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build.xml:108 : The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/build- java.xml:183: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/properti es.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/properti es.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/modules/acces sibility/build.xml:90: No supported regular expression ma tcher found Total time: 56 seconds Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 14:36:02 $ - - It seems as an ant bug. Could someone help me? I've never seen this error, but it looks like you are missing a regex implementation. The ant regexp glob mapper has some dependencies described at: http://ant.apache.org/manual/CoreTypes/mapper.html#regexp-mapper But basically it says you need: Ant comes with implementations for the java.util.regex package of JDK 1.4 or higher, jakarta-regexp and jakarta-ORO. I'm kind of surprised you don't have the first of these? Regards, Mark. - 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][jvmti] Last commit of Harmony-1582 brocks JVMTI support for DRLVM.
Pavel Rebriy wrote:
Fix for Harmony-1582 brocks initialization of JVMTI support. I'm
investigating the problem and going to create fixing JIRA as soon as
possible.
The fix is ready. See http://issues.apache.org/jira/browse/HARMONY-1826
Pavel, I have reviewed the patch in HARMONY-1826, and it looks great!
A couple of minor comments.
The change like this doesn't really move us closer to multi-VM support,
as the jni_env is hardcoded to the emitted code.
-s = mov(s, M_Base_Opnd(esp_reg, 0), Imm_Opnd((int)jni_native_intf)) ; //
o0=jni_native_intf
+s = mov(s, M_Base_Opnd(esp_reg, 0),
Imm_Opnd((int)p_TLS_vmthread-jni_env)) ; // o0=jni_native_intf
The following change seems to fix unrelated issue ('Fixed Single Step event
disabling'?),
so I think it would have been better if it filed as a separate JIRA/patch.
-
ti-vm_brpt-release_intf(vm_thread-ss_state-predicted_breakpoints);
-_deallocate((unsigned char *)vm_thread-ss_state);
-vm_thread-ss_state = NULL;
+if( vm_thread-ss_state ) {
+if( vm_thread-ss_state-predicted_breakpoints ) {
+
ti-vm_brpt-release_intf(vm_thread-ss_state-predicted_breakpoints);
+}
+_deallocate((unsigned char *)vm_thread-ss_state);
+vm_thread-ss_state = NULL;
+}
Anyway, I vote for a quick inclusion of this patch.
-
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] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest
I don't understand either: This is a low risk test fix. 2006/10/11, Fedotov, Alexei A [EMAIL PROTECTED]: Mikhail, I already got several personal feedbacks about these comments. I accept that they are not good. I tried to express an idea that JIRAs marked with this comment prevent getting 100% pass rate on DRLVM. When I search for Unit_Tests_Pass_on_DRLVM in comments I will get a list of bugs to fix. Any suggestions how the comment should like? My only requirement is to keep Unit_Tests_Pass_on_DRLVM lexem in this comment. IMHO It makes sense to discuss it on a separate thread with different subject, so that other people could notice that discussion and participate Thanks, Mikhail With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 2:37 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest Hi Alexei I'm sorry I comlpetely don't understand your comment (as well as a number of similar comments in other JIRAs) Thanks, Mikhail 2006/10/7, Alexei Fedotov (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY- 1670?page=comments#action_12440591 ] Alexei Fedotov commented on HARMONY-1670: - [drlvm][unit] Blocks http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM This is a low risk test fix. [classlib][luni] invalid testcase in ClassTest -- Key: HARMONY-1670 URL: http://issues.apache.org/jira/browse/HARMONY-1670 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Trivial Attachments: H-1670.patch The test_getDeclaredMethodLjava_lang_String$Ljava_lang_Class of modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/Clas sTes t.java checks if IllegalAccessException is thrown during invokation of private method of inner class. This is bad due to: 1) the check is invalid, see HARMONY-1309 for details; 2) The ClassTest is not appropriate for testing reflection, and this is already covered in j.l.reflect.* tests. -- 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] - 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: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
I suspect it was JRockit java, which crashed. Since Sun's jvm is hotspot, you have to force it into compiling the method. Otherwise it will interpret the method and everything will work fine. :) Pavel. On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Will this test pass on SUN or BEA JVM? I remember I tried something similar but one of the RIs crashed :) On 10/11/06, Pavel Pervov [EMAIL PROTECTED] wrote: (Branching from original thread as this is different problem than in the root message.) Mikhail, The following scenario will fail: 1) JIT compiles some method and resolves some class A through user defined class loader 2) user define class loader loads class A and triggers compilation of some of its methods 3) this method happens to depend on class A, and, thus, JIT resolves the class A through the same class loader Voila! We have the described situation. Regards, Pavel. -- Mikhail Fursov
Re: [DRLVM][JET] write barrier for Java (mmtk)
Robin, Thanks for helping clarify the issues. The MMTk code base we are using is what Steve Blackburn supplied us in mid July. I don't know when it will be suggested we move to a more recent version of MMTk. I suspect a major part of the confusion has been because of working with a code base where the Plan interface is in transition. In any case, please confirm that each java thread needs to put an instance of Plan in its thread-local storage and that writeBarrier() and alloc() virtual method entry points need to be materialized from thread-local Plan object. Also, please confirm (or deny) that we should never call VM.barriers.performWriteInBarrier(). It only should be called by internal MMTk methods (I think). On 10/11/06, Robin Garner [EMAIL PROTECTED] wrote: I think you must be looking at a fairly old version of MMTk. writeBarrier is an instance method of a MutatorContext (in org.mmtk.plan). MutatorContext exists to hold unsynchronized thread-local data structures. Particularly relevant to the write barrier, each mutator context has its own thread-local remset. All of the mutator context methods of MMTk need fast access to the MMTk thread local data structures, which is why they are instance methods. The other critical instance method of a MutatorContext is 'alloc', which also has it's thread-local chunk of the space(s) it allocates into. As far as the VM is concerned, it will be calling instance methods of a final class. The various classes in org.mmtk.plan.* aren't final, but the VM interface code is expected to wrap the currently selected plan in some final class. JikesRVM wraps the currently selected plan classes in a 'SelectedPlan', 'SelectedMutatorContext' etc. As far as the VM.barriers.performWriteInBarrier() call is concerned, the optimization required to devirtualize a call to a final method of a static final field shouldn't be too hard to implement. MMTk recently moved away from using static methods for this part of the interface, to the current abstract factory, and improved the structure of the software significantly. We don't want to go back! I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. well, it less 'breaks the architecture' than performs a no-op :) -- robin Weldon Washburn wrote: Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier. Sorry for the confusion. On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread [drlvm]Extending... This helper (a static method) can be inlined by JIT without any devirtualization and call any method needed from MMTk or native implementation. So JIT won't know if it works with MMTk or with a native GC: all you need is just to replace the Java version of the helper. ? -- 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] -- Weldon Washburn Intel Middleware Products Division
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
The test you described has a lot of hidden issues. For example: if Sun supports such situation only with interpreter (need to investigate), may be it's enough if we support it only with JET (in the default mode JET compiles all methods first)? In this case if we see ClassCircularityError in OPT we have a chance to return JIT_FAILURE to EM and ask EM to compile this method with JET? On 10/11/06, Pavel Pervov [EMAIL PROTECTED] wrote: I suspect it was JRockit java, which crashed. Since Sun's jvm is hotspot, you have to force it into compiling the method. Otherwise it will interpret the method and everything will work fine. :) Pavel. On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Will this test pass on SUN or BEA JVM? I remember I tried something similar but one of the RIs crashed :) On 10/11/06, Pavel Pervov [EMAIL PROTECTED] wrote: (Branching from original thread as this is different problem than in the root message.) Mikhail, The following scenario will fail: 1) JIT compiles some method and resolves some class A through user defined class loader 2) user define class loader loads class A and triggers compilation of some of its methods 3) this method happens to depend on class A, and, thus, JIT resolves the class A through the same class loader Voila! We have the described situation. Regards, Pavel. -- Mikhail Fursov -- Mikhail Fursov
Re: [classlib][em64t]Problems during classlib on em64t (revision 462753)
It is very strange but I have needed jdk jars --- compile-java: [echo] Compiling ACCESSIBILITY classes copy-resources: svn-info: build-jar: BUILD FAILED /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/build.xml:108: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/build- java.xml:183: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properties.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properties.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/modules/accessibility/build.xml:90: No supported regular expression matcher found Total time: 20 seconds Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 18:17:24 $ java -version java version 1.5.0_09 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode) Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 18:19:32 $ ant -version Apache Ant version 1.6.5 compiled on June 16 2006 Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 18:19:54 $ ls /usr/postinstall/ant/apache-ant-1.7.0Beta2/lib/ ant-antlr.jarant.jar ant-stylebook.jar ant-apache-bcel.jar ant-javamail.jar ant-swing.jar ant-apache-bsf.jar ant-jdepend.jar ant-trax.jar ant-apache-log4j.jar ant-jmf.jar ant-weblogic.jar ant-apache-oro.jar ant-jsch.jar jakarta-oro-2.0.8.jar ant-apache-regexp.jarant-junit.jar jakarta-regexp-1.4.jar ant-apache-resolver.jar ant-launcher.jar libraries.properties ant-commons-logging.jar ant-netrexx.jar README ant-commons-net.jar ant-nodeps.jarxercesImpl.jar ant-jai.jar ant-starteam.jar xml-apis.jar Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 18:20:16 $ - On 10/11/06, Mark Hindess [EMAIL PROTECTED] wrote: On 11 October 2006 at 16:18, Valentin Al. Sitnick (Moscow) [EMAIL PROTECTED] wrote: Hi, I've tried to build classlib on em64t workstation an got some problems: 0. Bug in depends.xml - hosts architectures defined with bug --- condition property=hack.arch value=ipf isset property=is.x86_64 / /condition --- small fix condition property=hack.arch value=ia64 isset property=is.ia64 / /condition condition property=hack.arch value=x86_64 isset property=is.x86_64 / /condition --- 1. ant (1.6.5 or 1.7.0.beta2 - I've tried to use both) cannot create symlinks. It is not serious porblem - it is possible to create these lintks manually 2. build process was interrupted by error: - - -really-link: check: -compile: [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build/classes [javac] Compiling 3397 source files to /home/angel/builds/harmony/suse- 10.1-em64t/clean/classlib/trunk/build/classes [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/deploy/jdk/jre/lib/boot call-modules-all: compile-java: [echo] Compiling ACCESSIBILITY classes copy-resources: [copy] Copying 1 file to /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build/classes svn-info: build-jar: BUILD FAILED /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build.xml:108 : The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/build- java.xml:183: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/properti es.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/properti es.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/modules/acces sibility/build.xml:90: No supported regular expression ma tcher
Re: [ant][classlib][em64t]Problems during classlib on em64t (revision 462753)
On 11 October 2006 at 18:26, Valentin Al. Sitnick (Moscow) [EMAIL PROTECTED] wrote: It is very strange but I have needed jdk jars Yeah. I thought when adding the regexp mapper dependency that this should be a non-issue since everyone will need 1.5 to compile anyway. Your setup looks like it has all three options to me. You could check the ant -v output but it'll be very verbose and I'm not certain it'll help with this problem. I've added an [ant] tag to the subject in the hope that Matt Benson will spot this thread and might offer some insight? Regards, Mark. --- compile-java: [echo] Compiling ACCESSIBILITY classes copy-resources: svn-info: build-jar: BUILD FAILED /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/build.xml:108 : The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/build- java.xml:183: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properti es.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properti es.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/modules/acces sibility/build.xml:90: No supported regular expression matcher found Total time: 20 seconds Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 18:17:24 $ java -version java version 1.5.0_09 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode) Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 18:19:32 $ ant -version Apache Ant version 1.6.5 compiled on June 16 2006 Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 18:19:54 $ ls /usr/postinstall/ant/apache-ant-1.7.0Beta2/lib/ ant-antlr.jarant.jar ant-stylebook.jar ant-apache-bcel.jar ant-javamail.jar ant-swing.jar ant-apache-bsf.jar ant-jdepend.jar ant-trax.jar ant-apache-log4j.jar ant-jmf.jar ant-weblogic.jar ant-apache-oro.jar ant-jsch.jar jakarta-oro-2.0.8.jar ant-apache-regexp.jarant-junit.jar jakarta-regexp-1.4.jar ant-apache-resolver.jar ant-launcher.jar libraries.properties ant-commons-logging.jar ant-netrexx.jar README ant-commons-net.jar ant-nodeps.jarxercesImpl.jar ant-jai.jar ant-starteam.jar xml-apis.jar Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk 18:20:16 $ - On 10/11/06, Mark Hindess [EMAIL PROTECTED] wrote: On 11 October 2006 at 16:18, Valentin Al. Sitnick (Moscow) [EMAIL PROTECTED] wrote: Hi, I've tried to build classlib on em64t workstation an got some problems: 0. Bug in depends.xml - hosts architectures defined with bug --- condition property=hack.arch value=ipf isset property=is.x86_64 / /condition --- small fix condition property=hack.arch value=ia64 isset property=is.ia64 / /condition condition property=hack.arch value=x86_64 isset property=is.x86_64 / /condition --- 1. ant (1.6.5 or 1.7.0.beta2 - I've tried to use both) cannot create symlinks. It is not serious porblem - it is possible to create these lintks manually 2. build process was interrupted by error: --- -- - -really-link: check: -compile: [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build/classes [javac] Compiling 3397 source files to /home/angel/builds/harmony/suse- 10.1-em64t/clean/classlib/trunk/build/classes [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/deploy/jdk/jre/lib/boot call-modules-all: compile-java: [echo] Compiling ACCESSIBILITY classes copy-resources: [copy] Copying 1 file to /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/build/classes svn-info: build-jar: BUILD FAILED
Re: [testing] test suite layout, testNG, and more
On 10/11/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 10/9/06, Richard Liang [EMAIL PROTECTED] wrote: On 10/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: What is the status of our discussions about new test suite layout? Long ago we decided not to move existing tests until we finish with that discussion but the discussion seems to be either dead or in coma It's not dead ;-) We are waiting for the completion of j.u.concurrent so that we could run a pilot and continue our discussion. Looking forward to ... btw, Harmony may also benifit from failure and rerun feature of TestNG. I believe developers will like it! Sure ;-) Does it make sense to continue putting the tests in order (according to the old model) and relayout them as soon as we finish the discussion? Yes, it does make sense. Before we draw any new conclusion about TestNG, I suggest we follow our existing testing conventions/guidelines. Thanks, Mikhail - 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] -- Best regards, Andrew Zhang -- 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]
[drlvm][build] Make svn stamping optional
Geir, Mark, any chance of HARMONY-1083 being committed? I've updated it to match the current trunk and also incorporated best practices from classlib's build system. Without this change the file version_svn_tag.h ends up changed after every build in my workspace, which is annoying. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] DRLVM build on Windows
That's great, thanks Salikh. Could we also stick a link to this page in the build readme? It would be good to make it as easy to find as possible for a first time (and the rest of us) DRLVM builder. Regards, Oliver Salikh Zakirov wrote: Oliver Deakin wrote: This should be listed somewhere under Gotchas while building DRLVM. It would be useful to have these helpful tips stored for future Harmony contributors. I see there are already some useful DRLVM docs on the website - perhaps some kind of build troubleshooting section would also be good? I've started a wiki page DRLVM Build Troubleshooting to collect such recipes. http://wiki.apache.org/harmony/DrlvmBuildTroubleshooting - 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]
[jira] 'Patch available' status
Hi, we had a discussion about adding new searchable 'Patch Available' status to JIRA [1] some time ago. Several people supported the idea, and there were no objections. However, no actions have been made. Geir, have you forgotten about it, or do you have some objections? [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[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: [wiki] frontpage outdated?
Salikh Zakirov wrote: Hi, after creating a wiki page http://wiki.apache.org/harmony/DrlvmBuildTroubleshooting I was wondering where to link it up, so that it would be 'clickable-through' from the start page. I haven't found any suitable place. Moreover, the front page contains a lot of stuff not directly related to the current state of the project. I suggest to clean up front page by moving most of its contents to pages like 'initial project proposals', 'bookmarks' etc. The content which I think is appropriate for the wiki front page are the following links * component links: class library, jchevm, drlvm * status page links * troubleshooting page links It looks like someone already started cleaning and created the page 'OldFrontPage', but the frontpage is still cluttered. Comments? That was me - I started as I thought the same thing. Go for it :) 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: [jira] 'Patch available' status
I'll take a look. -Mark. On 11 October 2006 at 20:03, Salikh Zakirov [EMAIL PROTECTED] wrote: Hi, we had a discussion about adding new searchable 'Patch Available' status to JIRA [1] some time ago. Several people supported the idea, and there were no objections. However, no actions have been made. Geir, have you forgotten about it, or do you have some objections? [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbo x/[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][build] Make svn stamping optional
I'll be happy to look at it. It is somewhat annoying, but very useful :) geir Salikh Zakirov wrote: Geir, Mark, any chance of HARMONY-1083 being committed? I've updated it to match the current trunk and also incorporated best practices from classlib's build system. Without this change the file version_svn_tag.h ends up changed after every build in my workspace, which is annoying. - 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] 'Patch available' status
Salikh Zakirov wrote: Hi, we had a discussion about adding new searchable 'Patch Available' status to JIRA [1] some time ago. Several people supported the idea, and there were no objections. However, no actions have been made. Geir, have you forgotten about it, or do you have some objections? I've been trying to get it to work as our default navigator. There is some issue with JIRa... You can create your own issue navigator and use that, which will show patch avail... geir [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[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][unit tests] the goal is to achieve 100% pass rate
Excellent. As appreciative as I am of J9, I can't wait to work in all-Harmony code :) geir Elena Semukhina wrote: Hello all, I think that the goal of running classlib unit tests on DRLVM with 100% pass rate could be worth to achieve. Actually today we have 99% (without awt/swing) but still have about 30 failures/errors. Most of them have been evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki which lists those JIRA issues: http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM Are there any volunteers to help with DRLVM bugs fixing? 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: [build] DRLVM build on Windows
Oliver Deakin wrote: Could we also stick a link to this page in the build readme? It would be good to make it as easy to find as possible for a first time (and the rest of us) DRLVM builder. Done as README-troubleshooting-link.patch in HARMONY-1828 (on top of HARMONY-1730 README.patch) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't get binary to work
I'm ready to install Gentoo to see if I can repeat it... what version? Armand Navabi wrote: Seemed promising, but this patch did not help. I ran java -Xtrace helloworld to see if it even got to the patched code, but it seems like my code hangs even before getting to that code. I'm really not sure what my next step is to try to get the VM up and running correctly. Armand -Original Message- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 1:54 AM To: harmony-dev@incubator.apache.org Subject: Re: Can't get binary to work 2006/10/9, Armand Navabi [EMAIL PROTECTED]: Yes, I am still having problems. Like I said, I am just trying to run the executable currently. I see the same problem I was seeing when I built the DRLVM. I downloaded the Latest Linux JRE snapshot build, set the JAVA_HOME, PATH and LD_LIBRARY_PATH environment variables and then tried to run helloworld. Sometimes the executable will print hello world! and then hang, and sometimes it will just hang. Same thing happens when I download and try to run the Latest Linux HDK with helloworld. Armand, The symptoms you are describing similar to investigation results of HARMONY-1816. It is interesting to see if the patch helps you. [0] http://issues.apache.org/jira/browse/HARMONY-1816 My platform is Linux Gentoo 2.6.17.8. Thanks, Armand -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Sunday, October 08, 2006 6:57 PM To: harmony-dev@incubator.apache.org Subject: Re: Can't get binary to work Are you still having problems Armand? Tim Armand Navabi wrote: I have been unable to figure out why I can't get the drlvm to run helloworld. The classlib with Intel's VM works fine. So now I thought I'd just see if I could download the binary and execute it (JRE), but it is behaving the same way (I guess this is to be expected, but I just wanted to make sure it wasn't something in the build process that was causing the trouble). When I run java by itself it executes without problem, when I run java helloworld it just hangs, and java -showversion will print version info and then hang right after that: [EMAIL PROTECTED] /scratch/anavabi/Harmony/harmony-jre-r450941/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 = r450941, (Sep 28 2006), Linux/ia32/gcc 3.4.6, release build http://incubator.apache.org/harmony (hangs here) Here are the environment variables that I think are relevant: LD_LIBRARY_PATH /scratch/anavabi/Harmony/harmony-jre-r450941/bin:/scratch/anavabi/Harmony/ha rmony-jre-r450941/bin/default/ PATH .:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/i686-pc-linux-gnu/gcc-bi n/3.4.6:/opt/ICAClient:/opt/sun-jdk-1.5.0.06/bin:/opt/sun-jdk-1.5.0.06/jre/b in:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/opt/eclipse-sdk-3.2.1 JAVA_HOME /scratch/anavabi/Harmony/harmony-jre-r450941/bin I'm on Gentoo 2.6.17.8. Any ideas what may be going on? Thanks, Armand -- 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] - 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] VM throws NullPointerException in case java.class.path is not set
Well, that's actually an interesting question... should the VM do it if
not set, or should the launcher do it? I think that based on the
principle of least surprise, it should be launcher.
The user uses the launcher, so the launcher should be nice to the user,
and current directory really is somewhat of a user-oriented concept,
and is what the human expects.
Programs use the VM, and I think the VM should be more strict for safety.
geir
Oliver Deakin wrote:
Geir Magnusson Jr. wrote:
Absolutely. And if not, even the principle of be kind to your users
dictates that we do something nice for them.
Agreed - being nice to the user where we can is a good thing! Having the
current directory on the classpath is pretty common - giving it to the
user by default costs nothing and saves them having to explicitly set it
in every launcher they write.
Regards,
Oliver
geir
Evgueni Brevnov wrote:
Oliver,
You have provided strong arguments that RI uses current directory by
default. I think it makes sense to be compatible with RI in this
particular case.
Thanks
Evgueni
On 10/10/06, Oliver Deakin [EMAIL PROTECTED] wrote:
I have just tried launching the RI with a simple launcher (very basic -
CreateJavaVM(),
finds and launches a class, then calls DestroyJavaVM()). The launcher
does not
set java.class.path, and executes the main method of the following
class:
public class SysInfo {
public static void main(String[] args) {
System.getProperties().list(System.out);
}
}
The java.class.path value is printed as:
java.class.path=
So it appears that java.class.path property is left empty by default.
However,
to have found the SysInfo class, the RI must have searched in the
current
directory. I can also instantiate other classes that are located in the
current
directory. So although the java.class.path is set to an empty string,
internally
there is a default inclusion of the current directory.
IMHO we follow the RI behaviour here, and have an implicit inclusion of
the current directory unless the classpath is explicitly set.
Regards,
Oliver
Evgueni Brevnov wrote:
It seems for me like pretty specified VM behavior to treat classpath
absence as take classes from current directory. At least RI does like
that when you don't specify classpath on command line.
Evgueni
On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Another solution could be a simple shutdown with the valid error
message.
Sometimes the error message is better than hidden behaviour.
So the alternative is to check all properties VM needs before
running
real
startup and fail if some of the properties are not found.
On 10/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Hi All,
Currently DRLVM starts with help of the launcher. The launcher
does a
lot of stuff required to create VM instatnce. As a part of its
job it
sets up java.class.path property. And this is good. What is not
good
that DRLVM crashes (actually throws NullPointerException in
initalization stage) if java.class.path is not set. I believe
it makes
sense to point java.class.path to current directory inside VM if
launcher doesn't set it.
What do u think?
Thanks
Evgueni
-
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
-
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]
-
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: [build] DRLVM build on Windows
what would be ideal is a patch for the website, so there's a pointer from the website to this content. Salikh Zakirov wrote: Oliver Deakin wrote: This should be listed somewhere under Gotchas while building DRLVM. It would be useful to have these helpful tips stored for future Harmony contributors. I see there are already some useful DRLVM docs on the website - perhaps some kind of build troubleshooting section would also be good? I've started a wiki page DRLVM Build Troubleshooting to collect such recipes. http://wiki.apache.org/harmony/DrlvmBuildTroubleshooting - 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][launcher]shall we handle the parameter -version and -showversion in launcher or vm?
Tony Wu wrote: I encounter an error[1] when run java -version with IBM VME today and it is ok on DRLVM. I wonder how to handle these simple parameters. Is there any decision about that? [1] [EMAIL PROTECTED]:~/harmony/workspace/trunk/deploy/jdk/jre/bin$ ./java -version Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. JVMJ9VM007E Command-line option unrecognised: -version HMYEXEL062E Internal VM error: Failed to create Java VM FAILED to invoke JVM. Yes, we won't pass -version into the VM, but simply have an expectation that the VM will set a property that can be read by the launcher post VM init. 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] smoke test : gc PhantomReferenceQueueTest is really unstable
fabulous! Pavel Pervov wrote: Geir, sorry for confusion. The bug you are referring to is described in [1]. Regards, Pavel. [1] *http://issues.apache.org/jira/browse/HARMONY-1814*http://issues.apache.org/jira/browse/HARMONY-1814 On 10/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I get this more often than not. Can someone interested take a look? Happens w/ jitrino : java: /home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:524: const char* class_get_name(Class*): Assertion `cl' failed. SIGABRT in VM code. Stack trace: addr2line: '[vdso]': No such file 1: ?? (D7^CCA5FEB6A8DCFDA4FFE8E3B6:-1) java: /home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:524: const char* class_get_name(Class*): Assertion `cl' failed. SIGABRT in VM code. Stack trace: addr2line: '[vdso]': No such file 3: ?? (D7^CCA5FEB6B8C8BABFFFE8E3B6:-1) 2: abort (??:-1) 4: __assert_fail (??:-1) 5: abort (??:-1) 6: __assert_fail (??:-1) 7: class_get_name (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:525) 8: class_get_name (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:525) 9: Jitrino::Jet::is_magic(Class*) (??:-1) 10: Jitrino::Jet::Compiler::gen_magic() (??:-1) 11: Jitrino::Jet::Compiler::handle_inst() (??:-1) 12: Jitrino::Jet::is_magic(Class*) (??:-1) 13: Jitrino::Jet::Compiler::gen_magic() (??:-1) 14: Jitrino::Jet::Compiler::handle_inst() (??:-1) 15: Jitrino::Jet::Compiler::comp_gen_insts(unsigned int, unsigned int, unsigned int) (??:-1) 16: Jitrino::Jet::Compiler::comp_gen_code_bb(unsigned int) (??:-1) 17: Jitrino::Jet::Compiler::comp_gen_insts(unsigned int, unsigned int, unsigned int) (??:-1) 18: Jitrino::Jet::Compiler::comp_gen_code_bb(unsigned int) (??:-1) 19: Jitrino::Jet::Compiler::compile(void*, Method*, OpenMethodExecutionParams const) (??:-1) 20: Jitrino::Jet::Compiler::compile(void*, Method*, OpenMethodExecutionParams const) (??:-1) 21: Jitrino::Jet::compile_with_params(void*, void*, Method*, OpenMethodExecutionParams) (??:-1) 22: Jitrino::Jet::compile_with_params(void*, void*, Method*, OpenMethodExecutionParams) (??:-1) 23: JIT_compile_method_with_params (??:-1) 24: JIT_compile_method_with_params (??:-1) 25: Dll_JIT::compile_method_with_params(void*, Method*, OpenMethodExecutionParams) (/home/geir/dev/apache/harmony/enhanced/trunk/working_v m/vm/vmcore/include/dll_jit_intf.h:86) 26: compile_do_compilation_jit(Method*, JIT*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:700) 27: vm_compile_method (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:2539) 28: Dll_JIT::compile_method_with_params(void*, Method*, OpenMethodExecutionParams) (/home/geir/dev/apache/harmony/enhanced/trunk/working_v m/vm/vmcore/include/dll_jit_intf.h:86) 29: compile_do_compilation_jit(Method*, JIT*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:700) 30: vm_compile_method (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:2539) 31: DrlEMImpl::compileMethod(Method*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/em/src/DrlEMImpl.cpp:520) 32: CompileMethod (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/em/src/em_intf.cpp:50) 33: compile_do_compilation (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:780) 34: compile_jit_a_method(Method*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:828) 35: IP is 0xB6891172 native code 36: java/lang/FinalizerThread.wakeupFinalization()V (??:-1) 37: java/lang/FinalizerThread.startFinalization(Z)V (??:-1) 38: vm_invoke_native_array_stub (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/util/ia32/base/invoke_native_stub_i a32.asm:41) 39: JIT_execute_method_default(void*, _jmethodID*, jvalue*, jvalue*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/sr c/util/ia32/base/ini_iA32.cpp:200) 40: DrlEMImpl::compileMethod(Method*) (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/em/src/DrlEMImpl.cpp:520) 41: CompileMethod (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/em/src/em_intf.cpp:50) 42: compile_do_compilation (/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:780) 43: compile_jit_a_method(Method*)
Re: [drlvm][jvmti] Last commit of Harmony-1582 brocks JVMTI support for DRLVM.
If all agree, please submit your change as a patch to that patch :)
Salikh Zakirov wrote:
Pavel Rebriy wrote:
Fix for Harmony-1582 brocks initialization of JVMTI support. I'm
investigating the problem and going to create fixing JIRA as soon as
possible.
The fix is ready. See http://issues.apache.org/jira/browse/HARMONY-1826
Pavel, I have reviewed the patch in HARMONY-1826, and it looks great!
A couple of minor comments.
The change like this doesn't really move us closer to multi-VM support,
as the jni_env is hardcoded to the emitted code.
-s = mov(s, M_Base_Opnd(esp_reg, 0), Imm_Opnd((int)jni_native_intf)) ; //
o0=jni_native_intf
+s = mov(s, M_Base_Opnd(esp_reg, 0),
Imm_Opnd((int)p_TLS_vmthread-jni_env)) ; // o0=jni_native_intf
The following change seems to fix unrelated issue ('Fixed Single Step event
disabling'?),
so I think it would have been better if it filed as a separate JIRA/patch.
-
ti-vm_brpt-release_intf(vm_thread-ss_state-predicted_breakpoints);
-_deallocate((unsigned char *)vm_thread-ss_state);
-vm_thread-ss_state = NULL;
+if( vm_thread-ss_state ) {
+if( vm_thread-ss_state-predicted_breakpoints ) {
+
ti-vm_brpt-release_intf(vm_thread-ss_state-predicted_breakpoints);
+}
+_deallocate((unsigned char *)vm_thread-ss_state);
+vm_thread-ss_state = NULL;
+}
Anyway, I vote for a quick inclusion of this patch.
-
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: Can't get binary to work
Geir Magnusson Jr. wrote: I'm ready to install Gentoo to see if I can repeat it... what version? Version 2.6.17.8. I think some people have got it to work on Gentoo. I'm not sure what version they had. Armand Armand Navabi wrote: Seemed promising, but this patch did not help. I ran java -Xtrace helloworld to see if it even got to the patched code, but it seems like my code hangs even before getting to that code. I'm really not sure what my next step is to try to get the VM up and running correctly. Armand -Original Message- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 1:54 AM To: harmony-dev@incubator.apache.org Subject: Re: Can't get binary to work 2006/10/9, Armand Navabi [EMAIL PROTECTED]: Yes, I am still having problems. Like I said, I am just trying to run the executable currently. I see the same problem I was seeing when I built the DRLVM. I downloaded the Latest Linux JRE snapshot build, set the JAVA_HOME, PATH and LD_LIBRARY_PATH environment variables and then tried to run helloworld. Sometimes the executable will print hello world! and then hang, and sometimes it will just hang. Same thing happens when I download and try to run the Latest Linux HDK with helloworld. Armand, The symptoms you are describing similar to investigation results of HARMONY-1816. It is interesting to see if the patch helps you. [0] http://issues.apache.org/jira/browse/HARMONY-1816 My platform is Linux Gentoo 2.6.17.8. Thanks, Armand -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Sunday, October 08, 2006 6:57 PM To: harmony-dev@incubator.apache.org Subject: Re: Can't get binary to work Are you still having problems Armand? Tim Armand Navabi wrote: I have been unable to figure out why I can't get the drlvm to run helloworld. The classlib with Intel's VM works fine. So now I thought I'd just see if I could download the binary and execute it (JRE), but it is behaving the same way (I guess this is to be expected, but I just wanted to make sure it wasn't something in the build process that was causing the trouble). When I run java by itself it executes without problem, when I run java helloworld it just hangs, and java -showversion will print version info and then hang right after that: [EMAIL PROTECTED] /scratch/anavabi/Harmony/harmony-jre-r450941/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 = r450941, (Sep 28 2006), Linux/ia32/gcc 3.4.6, release build http://incubator.apache.org/harmony (hangs here) Here are the environment variables that I think are relevant: LD_LIBRARY_PATH /scratch/anavabi/Harmony/harmony-jre-r450941/bin:/scratch/anavabi/Harmony/ha rmony-jre-r450941/bin/default/ PATH .:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/i686-pc-linux-gnu/gcc-bi n/3.4.6:/opt/ICAClient:/opt/sun-jdk-1.5.0.06/bin:/opt/sun-jdk-1.5.0.06/jre/b in:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/opt/eclipse-sdk-3.2.1 JAVA_HOME /scratch/anavabi/Harmony/harmony-jre-r450941/bin I'm on Gentoo 2.6.17.8. Any ideas what may be going on? Thanks, Armand -- 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] - 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][jvmti] Last commit of Harmony-1582 brocks JVMTI support for DRLVM.
Geir Magnusson Jr. wrote: If all agree, please submit your change as a patch to that patch :) Sorry for confusion, it wasn't my change, but commented changes from HARMONY-1826. - 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] 'Patch available' status
Geir Magnusson Jr. wrote: You can create your own issue navigator and use that, which will show patch avail... I am not sure I understand this completely. Issue navigator allows me to define my filters and customize column presence and order. I still do not understand how to get 'patch available' information. There exists 'patch info' column, but somehow it is not shown on the issue list page even if it was enabled on the column configuration page. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Sveta, I looked through the README doc. The latest patch looks significantly better then the first one. The only item is missed is that we have 3 different GC folders today on the top level. On 10/11/06, Konovalova, Svetlana [EMAIL PROTECTED] wrote: Folks, I took a close look at the README file and Quick Help pages for users [1] and developers [2] and created patches for these three docs [JIRA 1730] https://issues.apache.org/jira/browse/HARMONY-1730 Taking into consideration latest changes, I fixed duplication of info and out-dated content, and tried to improve language in some places. It would be great if someone can find a chance to look at the patches. Your feedback is very important! -- Mikhail Fursov
Re: [DRLVM][JET] write barrier for Java (mmtk)
hmm we may have version skew going on here. Mikhail, Robin can we stay with the July 14 (or there abouts) version that Steve Blackburn posted to his web page? On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/11/06, Weldon Washburn [EMAIL PROTECTED] wrote: Robin, Thanks for helping clarify the issues. The MMTk code base we are using is what Steve Blackburn supplied us in mid July. Looks like 'unboxed' package from MMTk has been updated recently too. I've found 'Address::prefetchNTA()' op today we do not have in our version. -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division
Re: [jira] 'Patch available' status
Salikh Zakirov wrote: Geir Magnusson Jr. wrote: You can create your own issue navigator and use that, which will show patch avail... I am not sure I understand this completely. Issue navigator allows me to define my filters and customize column presence and order. I still do not understand how to get 'patch available' information. it's one of the possible columns. There exists 'patch info' column, but somehow it is not shown on the issue list page even if it was enabled on the column configuration page. I know - that's what I think is a bug... - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] -verbose option does nothing
Hi, I have noted the than java -verbose does not print any information, is that normal? Cheers Jean-Frederic PS: It looks is set correctly in vm/vmcore/src/init/parse_arguments.cpp: set_threshold(util::CLASS_LOGGER, INFO); - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
On Wednesday 11 October 2006 16:15 Pavel Pervov wrote: (Branching from original thread as this is different problem than in the root message.) Wasn't it the same problem, just happening on classlib initialization? I think the scenario is the same. The following scenario will fail: 1) JIT compiles some method and resolves some class A through user defined class loader 2) user define class loader loads class A and triggers compilation of some of its methods 3) this method happens to depend on class A, and, thus, JIT resolves the class A through the same class loader Voila! We have the described situation. A synthetic test for drlvm could really help to emphasize the problem. Then we can run this test on all other VMs with possible modifications. BTW sun's hotspot should compile a method if it is called several times, so user defined class loader could do something like calling this method many times to trigger its compilation. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't get binary to work
On Wednesday 11 October 2006 20:36 Geir Magnusson Jr. wrote: I'm ready to install Gentoo to see if I can repeat it... what version? Gentoo is a strange and weird distribution. It has no version :) It has versions for individual packages only. It has profile version like 2006.1 with compilation flags for some key packages. But except for that Gentoo could be used for a very long time and the package versions are determined only by the choice of the user. Armand refers to the kernel version. It is 2.6.17-r8 which is the latest stable for x86 and amd64 architectures. But referring just to kernel version in Gentoo is not correct. Any package of any version may exist in installation, so it is better to specify at least glibc, gcc (with flags specified in /etc/make.conf), libstdc++ and binutils versions when referring to Gentoo installation. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] the big soup of VM properties (HARMONY-1626)
On Wednesday 11 October 2006 09:41 Mikhail Fursov wrote: +1 to Eugueni and Alexey and -1 to use String type in the intercomponent interface. + AFAIK the String type is VM internal type only. Ok you've convinced me. +1 for const char * On 10/11/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/11, Evgueni Brevnov [EMAIL PROTECTED]: Gregory, My 2cents: 1cent) I think we should not integrate property module so tight (by using StringPool) with VM internals. Let it be independent enough. 2cent) I also don't think we should pollute StringPool any further. Instead I would like to see if we can get it smaller say by splitting into two pools whatever... Agreed. Besides properties are used in VM almost solely during init, no performance gain here. So -1 to using Strings for properties. Evgueni On 10/11/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 10 October 2006 11:36 Geir Magnusson Jr. wrote: Inline Dmitry Yershov wrote: [snip] VM properties proposal == The general purpose of VM Properties subcomponent is to provide centralized access to a common properties table. A property is meant as a pair of key and value. The properties stored in VM Properties table represent configuration settings for a separate component (such as VMCore, GC, JIT etc) or for the whole system. Another use case for the properties is communication between different components. Requirements 1) The key and value are represented as string (i.e. char*). and I propose that on each operation, a copy is made, so that the caller frees the string that they got or gave. Hmm... I thought of another type. VM has a String class which represents an internal strings implementation. String pointers all refer to the same interned const char * memory location so comparing them is faster, you just compare pointers. Would it be better to have key and value be String * instead of const char *? It would save memory allocation, copying and comparing and lookup in properties hash table could be done using a pointer. I don't think it is a very performance critical place, properties aren't accessed very often, but at least it may reduce memory footprint and will cause less memory leaks when someone forgets to free a returned copy. On the other hand, String storage is global to the whole VM, so there are tons of strings kept inside of it. Lookup inside of a small hash table like properties may be much faster than lookup through all the strings that VM keeps... Hmm now I am not sure I want to suggest this way, just want it to be considered. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target
On Wednesday 11 October 2006 05:28 Leo Li wrote: But I cannot find the rpm for liblcms.a and icc34.h in the CD. There is no liblcms*.rpm or lcms*.rpm. And what do you mean official mirror, the redhat site? Although I admit rpmfind is not a good way, but it really works after I installed all the necessary packages and put the required files to the appropriate position. At least Harmony should gives some hints, for example, which rpm is required and where to get them. Since not every body is an expert of rpm, and aware of the relationship between the required files and rpms, as well as their versions, as you said, the rpm hell. Yes I agree that there should be some necessary library requirements for building all of the harmony components, and these requirements should be described in some place. This was agreed in another branch of this thread. As to rpm packages, send me a email directly, please write which version of redhat you have installed. I am sure I can help you with installing the necessary packages. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Using latest linux snapshot[hdk]...
On Wednesday 11 October 2006 14:44 Ilya Okomin wrote: On 10/11/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 10 October 2006 13:02 Ilya Okomin wrote: On 10/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Yeah, I would have been surprised it that worked. Why not just install v 6? I have libstdc++.so.6 on my system. Nevertheless I have the same results as Dmitry described: bash-2.05b$ ./java -version Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. Failed to open JVM DLL: /work/Harmony/builds/harmony-jre-latest/bin/default/harmonyvm (/lib/ssa/libstdc++.so.6: version `GLIBCXX_3.4' not found (required by /work/Harmony/builds/harmony-jre-latest/bin/default/libharmonyvm.so)) I used harmony-jre-r450941 snapshot. Should I do anything else to resolve this issue? It is probably because your custom libstdc++ is still compiled against an older glibc version of your distribution. Geir uses more modern version. Can you run /lib/libc.so.6 and show the output? You've asked about libc.so.6 output, here it is: GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2.3 20030502 (Red Hat Linux 3.2.3-53). Compiled on a Linux 2.4.20 system on 2005-09-16. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy The C stubs add-on version 2.1.2. BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. I hope this information will clear some questions. Well it shows that you have glibc 2.3.x and the more modern version is 2.4 which I use. If you ask me about why GLIBCXX_3.4 uses version 3, I really don't know. But still I think the version numbers for binary builds which Geir creates are referring to glibc and running these binaries on the more recent Linux installations shouldn't be a problem. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [tests] Can anyone explain what these are for?
On 10/11/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Some tests for beans contained the code like this:
---
public void testGetArguments() {
// Covered in the testcases for the constructor
}
public void testGetMethodName() {
// Covered in the testcases for the constructor
}
---
I just commented it out. I could simply delete it but decided that we
may need it in the future. When we finish with 1.5 and everybody will
have a lot of free time - we can get back to it and think again: do we
need to insert an additional test case here?
Yes. My suggestion is marking these tests with TODO. It's easy for
remindering. Eventually, we'll decide whether removing the TODOs or writing
more test code there.
Thanks!
2006/10/11, Richard Liang [EMAIL PROTECTED]:
On 10/11/06, Nathan Beyer [EMAIL PROTECTED] wrote:
Perhaps, but there are much better ways of determining that. From just
reading the test code to code coverage tools.
From my analysis, these were part of the large test contribution and
indicated that there wasn't an explicit test for that method. In most
cases, there were tests for these methods, either in other classes or
in other methods of the class.
Nathan, I agree ;-)
-Nathan
On 10/10/06, Richard Liang [EMAIL PROTECTED] wrote:
On 10/11/06, Nathan Beyer [EMAIL PROTECTED] wrote:
I've seen a few and I've deleted any that I've come across. I would
say feel free to delete them too. I've also been deleting empty
setup
and teardown methods too.
Please do not simply delete them. Maybe that means we are lack of the
test for some methods, for example getInetAddress.
-Nathan
On 10/10/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
These could be a result of copy/paste tests creation.
And I'm curious why it was written for the first time. :)
SY, Alexey
2006/10/10, Mark Hindess [EMAIL PROTECTED]:
I've come across a couple of tests with things like:
public void test_getInetAddress() {
assertTrue(Used to test, true);
}
Can anyone explain why we have these?
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best regards,
Andrew Zhang
Re: [classlib][util.prefs] Implementation should be compatible with RI
Can you provide a patch for the test case that correctly asserts the specification's contract and passes on the RI? This may help for someone to provide a fix for the issue. -Nathan On 10/11/06, Elena Semukhina [EMAIL PROTECTED] wrote: Hi all, org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest fails on some machines when there are restrictions in access to system registry. https://issues.apache.org/jira/browse/HARMONY-1751 describes the issue. It looks like Harmony implementation does not follow spec for Preferences.systemNodeForPackage(). Besides, the test is incorrect as well because it does not expect java.util.prefs.BackingStoreException on Preferences.childrenNames() and fails on RI. Could anyone look into the issue? -- 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: [General]Do we need an instruction of trying HDK on applications?
On 10/11/06, Tony Wu [EMAIL PROTECTED] wrote: Hi all, I have not found a guideline or instruction for trying hdk on applications. And I think something like how to try harmony on applications will do some help for those who have interest in this job. These days I'm struggling on running Apache Ant on Harmony and get some experience. Let me post these points as a start :) Please correct me if I am wrong. Download the application code, record its revision.(If a stable version is preferred here?) Verify latest hdk via, 1. If there are tests of the application, run the tests on RI and Harmony and record the difference. 2. If there are examples supplied, try to get them working on harmony to see if there is unexpected behavior. 3. Do some simple trial like real customer following the application's installation/user-guide. Post what and how you did on harmony wiki, http://wiki.apache.org/harmony/ClassLibrary Dive into the result to find if it is a bug of Harmony. Raise JIRA or post on mailing list if necessary. something needs attention, 1.Make sure you are running right JDK. 2.Record any special settingssteps on harmony wiki. Suggestions? Comments? Additions? IMHO, it should be very helpful to users. ;-) -- Tony Wu 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] -- 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]
[classlib]Self-host of Derby
Hi, all: I now plan to make the self-host of Derby on Harmony. Is there anyone interested in this topic? Here is what I encountered in the process. Hope it will be helpful to anybody who is interested in it. At first, the testcases even fails on RI both on windows and ubuntu and the result are different.??? After some struggiling, I have successfully passed the provided testcases on RI after I rebuild the source on my machine. But there still remains a problem: The derby team kindly rewrite the launcher for testcases in order to treat J9 vm differently if the property java.vm.name starts with j9. But the j9 vm used in Harmony has been customized thus is different from traditional j9 vm that is expected by derby. This leads to failure to launch tests. I will talk on Derby's mailing list to find a solution. -- Leo Li China Software Development Lab, IBM
RE: Can't get binary to work
Gentoo version information:
Glibc: 2.3.6
[EMAIL PROTECTED] /usr/lib/libstdc++-v3 $ /lib/libc.so.6
GNU C Library stable release version 2.3.6, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0,
pie-8.7.9).
Compiled on a Linux 2.6.11 system on 2006-05-03.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.10 by Xavier Leroy
The C stubs add-on version 2.1.2.
GNU Libidn by Simon Josefsson
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
For bug reporting instructions, please see:
http://www.gnu.org/software/libc/bugs.html.
gcc version
[EMAIL PROTECTED] /usr/lib/libstdc++-v3 $ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/specs
Configured with:
/scratch/portage/tmp/portage/gcc-3.4.6-r1/work/gcc-3.4.6/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.6
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/g++-v3
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-nls --with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --disable-multilib --enable-java-awt=gtk
--enable-languages=c,c++,java,f77 --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
/etc/make.conf:
# this file was generated by /p/portage/20060616/sbin/genmakeconf
CFLAGS=-pipe -O2 -march=pentium4 -mfpmath=sse
CHOST=i686-pc-linux-gnu
CLEAN_DELAY=0
CXXFLAGS=${CFLAGS}
DISTDIR=/p/portage/distfiles
FEATURES=buildpkg
GENTOO_MIRRORS=ftp://csociety-ftp.ecn.purdue.edu/pub/gentoo;
MAKEOPTS=-j2
PKGDIR=/p/portage/20060616/packages/x86/pentium4
PORTAGE_TMPDIR=/scratch/portage/tmp
PORTDIR_OVERLAY=/p/portage/20060616/overlay
#PORT_LOGDIR=/scratch/portage/log
SYNC=rsync://rsync25.us.gentoo.org/gentoo-portage
USE=sse sse2
libstdc++ version
[EMAIL PROTECTED] /usr/lib/libstdc++-v3 $ ls
libstdc++.so.5 libstdc++.so.5.0.6
Let me know if you need any other information.
Thanks,
Armand
-Original Message-
From: Gregory Shimansky [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 11, 2006 7:39 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Can't get binary to work
On Wednesday 11 October 2006 20:36 Geir Magnusson Jr. wrote:
I'm ready to install Gentoo to see if I can repeat it... what version?
Gentoo is a strange and weird distribution. It has no version :) It has
versions for individual packages only.
It has profile version like 2006.1 with compilation flags for some key
packages. But except for that Gentoo could be used for a very long time and
the package versions are determined only by the choice of the user.
Armand refers to the kernel version. It is 2.6.17-r8 which is the latest
stable for x86 and amd64 architectures. But referring just to kernel version
in Gentoo is not correct. Any package of any version may exist in
installation, so it is better to specify at least glibc, gcc (with flags
specified in /etc/make.conf), libstdc++ and binutils versions when referring
to Gentoo installation.
--
Gregory Shimansky, Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
