Re: [classlib][concurrent] Complete support?
Guys, to get a consensus on the interfaces is very good, but this issue is not about interfaces. j.u.concurrent.atomic.AtomicLong in its original implementation has private native method: boolean VMSupportsCS8(), thus to work with original concurrent classes any VM should export following function: JNIEXPORT jboolean JNICALL Java_java_util_concurrent_atomic_AtomicLong_VMSupportsCS8(JNIEnv *, jclass); So the question here is what is the best place to put this function declaration in. For now the most logical place in DRLVM for me is: vmcore/src/kernel_classes/native/org_apache_harmony_util_concurrent_Atomics.h But as soon as the rest of those functions may soon be replaced with accessors, probably it makes sense to choose different place. Any thought on what is best place to put this function to? Nik. On 11/8/06, Nathan Beyer [EMAIL PROTECTED] wrote: Instead of continuing to add functionality to the DRLVM-specific Atomics class, I'd like to get a consensus on the Threads/Objects (include CAS operations) interfaces in luni-kernel. Then we can get DRLVM to implement these classes and the donated IBM VM to do the same so we can have concurrent support from both VMs. -Nathan On 11/7/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: please see the following JIRA issue for the missing function: http://issues.apache.org/jira/browse/HARMONY-2086 Nik. On 11/7/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: While I'm not familiar with j.u.concurrent build infrastructure, but the issue about missing native function is known and I'll file a jira and provide a fix today. Nik. 1) Natives are missing. In particular, java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be implemented on VM side. 2) ant test -Dbuild.module=concurrent does not work. The output is as follows: support-jar: [jar] Building jar: C:\_work_\harmony\enhanced\classlib\trunk\deploy\build \test\support.jar test-modules: test: full-report: BUILD FAILED C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error occ urred while executing this line: C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58: C:\_work_\harm ony\enhanced\classlib\trunk\build\test_report not found. Do I miss something important? -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [classlib][concurrent] Complete support?
While I'm not familiar with j.u.concurrent build infrastructure, but the issue about missing native function is known and I'll file a jira and provide a fix today. Nik. 1) Natives are missing. In particular, java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be implemented on VM side. 2) ant test -Dbuild.module=concurrent does not work. The output is as follows: support-jar: [jar] Building jar: C:\_work_\harmony\enhanced\classlib\trunk\deploy\build \test\support.jar test-modules: test: full-report: BUILD FAILED C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error occ urred while executing this line: C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58: C:\_work_\harm ony\enhanced\classlib\trunk\build\test_report not found. Do I miss something important? -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [classlib][concurrent] Complete support?
please see the following JIRA issue for the missing function: http://issues.apache.org/jira/browse/HARMONY-2086 Nik. On 11/7/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: While I'm not familiar with j.u.concurrent build infrastructure, but the issue about missing native function is known and I'll file a jira and provide a fix today. Nik. 1) Natives are missing. In particular, java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be implemented on VM side. 2) ant test -Dbuild.module=concurrent does not work. The output is as follows: support-jar: [jar] Building jar: C:\_work_\harmony\enhanced\classlib\trunk\deploy\build \test\support.jar test-modules: test: full-report: BUILD FAILED C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error occ urred while executing this line: C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58: C:\_work_\harm ony\enhanced\classlib\trunk\build\test_report not found. Do I miss something important? -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [drlvm] Is it time to say goodbye to dear friend GC v4?
Let me answer for Artem :), he is on vacation and most probably won't answer soon. We do occasionally use GCv4 to verify some threading issues, since native threading resource allocation depends on weak references. Thus I would agree with Ivan, that sometimes it is helpful to switch to different code base(which is handy and considered to be stable enough), but if gcv4 won't be supported any more why don't drop it having in mind that one can always take older revisions from SVN. +1 for dropping GCv4 Nik. On 11/2/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: I would like to know the opinion of Artem, Salikh and Alexey Ignatenko. They have used the GC and may have reasons to keep it. As for me, I occasionally use it (GCv4) and a modified version of GCv4.1 (which can help detect heap access via lost pointers). Most of the time I prefer second one, but sometimes it is helpful to run with completely different code base. I didn't try GCv5 yet. If it stable I will switch to it. -- Ivan On 11/2/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Is there any reason to keep this around in the main branch?
Re: [drlvm] what's the difference between the structure VM_thread and HyThread?
Hello, this is legacy thread structure. You're right, there was no HyThread at first, but VM_thread structure. Also different DRLVM modules used to have dedicated fields in this structure. Further it was decided to make threading module independent and make usage model of threading module the same for all other modules(i.e use thread local storage for module specific data). But since VM_thread structure usage was very heavy it was also decided to leave all non threading data in VM_thread and put it in TLS till better times (I mean, till this data will be divided into module depended parts and also put into TLS under different keys). Nik. On 10/30/06, Fan Bin [EMAIL PROTECTED] wrote: Hi all, I'm now reading the lastest version of drlvm. Now I have a question about the thread management module. I see that there are three kinds of control blocks: HyThread, JVMTIThread and VM_thread. What's the difference of their rols? Especially HyThread and VM_thread. As far as I know, there is no HyThread at first. Thanks, Fan Bin
Re: [drlvm] what's the difference between the structure VM_thread and HyThread?
Yes, this data is non threading and separate fields of VM_thread structure should be replaced with independent values (data structures) stored in TLS under separate keys. Nik. On 10/30/06, Fan Bin [EMAIL PROTECTED] wrote: Thanks, so you mean that there is only non threading data currently in VM_thread block, and maybe the VM_thread block will be replaced by TLS in HyThread, right? Bin - Original Message - From: Nikolay Kuznetsov [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Sent: Monday, October 30, 2006 9:13 PM Subject: Re: [drlvm] what's the difference between the structure VM_thread and HyThread? Hello, this is legacy thread structure. You're right, there was no HyThread at first, but VM_thread structure. Also different DRLVM modules used to have dedicated fields in this structure. Further it was decided to make threading module independent and make usage model of threading module the same for all other modules(i.e use thread local storage for module specific data). But since VM_thread structure usage was very heavy it was also decided to leave all non threading data in VM_thread and put it in TLS till better times (I mean, till this data will be divided into module depended parts and also put into TLS under different keys). Nik. On 10/30/06, Fan Bin [EMAIL PROTECTED] wrote: Hi all, I'm now reading the lastest version of drlvm. Now I have a question about the thread management module. I see that there are three kinds of control blocks: HyThread, JVMTIThread and VM_thread. What's the difference of their rols? Especially HyThread and VM_thread. As far as I know, there is no HyThread at first. Thanks, Fan Bin
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Hello All, in general we do not have any objections to implement such functionality, but as far as I understand this will be quite unique TM feature (no other threading library have this, or give me a link) which is intended to improve performance. And if we going to extend TM interface for this, I would like to have any performance data beforehand, do we any data? Thank you. Nik. On 10/25/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Xiao-Feng, I think there should be no problem to get this to work. But, I also agree with Mikhail that it could be benefitial to have data directly available in TLS without additional pointer dereference. If we will have corresponding interface function to allocate more then one void pointer at once in TLS it can be used as optimization. -- Ivan On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Why do we need multiple slots? Can't we use just one slot, which stores a pointer to a user data structure (the GC_Thread_Info in this case)? Yes you can store a pointer. But in this case you can't tell that you have constant offset from fs[14] to your data for all threads. So you can't inline your helper in JIT. Why? As long as we keep the offset_of_free to the pointer be constant and known to JIT helper, we only need an additional dereference to get the free value. We have two constant offsets, one is the pointer (to gc_tls_data) offset in fs[14], the other is the free offset in gc_tls_data. Thanks, xiaofeng -- Mikhail Fursov
Re: [drlvm][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
Evgueni, first of all I'd like to emphasize that suspend/resume_all functions are potentially unsafe and should be used with care. secondly, those methods were designed mainly to support stop_the_world_enumeration and thus usually being used under certain conditions. hmmm... it is strange to hear words like that. TM provides specification for this particular method and it should perform according to that specification. I as a developer don't want to care about particular use case scenario. I'd say that w/o stop_the_world enumeration we would not include this function to the interface, and w/o Thread,stop()(which is deprecated and jvmtiThreadStop which is used in debugger) we would not include even suspend function to the interface, like pthread or original version of hythread. Most of the others implementations have some special notes about suspend: MSDN: This function is primarily designed for use by debuggers. It is not intended to be used for thread synchronization. HP pthread_suspend_np(not portable): This functionality enables a process that is multithreaded to temporarily suspend all activity to a single thread of control. When the process is single threaded, the address space is not changing, and a consistent view of the process can be gathered. So, this function is unsafe, and should be used with care and In specific, with a solid model of system behavior in mind.(c) Weldon; And returning to the question of safepoints inside suspend_disable regions, we have a lot of such places inside a VM and suspend_all is probably the only place where this safepoint was left intentionally(I mean cyclic suspends). Nikolay, I understand there is only one use case for now. Again I expect the method works according to the spec but not how it is used in some particular case. Could you clarify what you mean by saying Till now suspend_all method was designed to work within one group(in particular default group, containing java threads), and called be GC. Why do you have such restriction? Where it is specified? We have such restrictions, because it's extremly hard to implement common(not only for GC + limited use of TI). The spec on suspend/suspend_all function usage scenarious can be found at: drlvm/trunk/vm/thread/doc/ThreadManager.htm paragraphs 6.2 and 6.3 Thank you. Nik. - 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][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
hmm I never thought of it that way. My initial reaction is no. Suspend enable/disable and global thread lock are seperate, distinct concepts. The thread lock should protect the VM internal thread structs when they are being modified. For example, the thread lock should allow only one thread create/die at any given instant. The enable/disable state is incidental to this event. This is independent of the concept of a thread running native code being in a state where the GC can find all its live references. If a thread needs to grab the thread lock, of course, it needs to put itself in a suspend enable mode because it might have to wait for the lock. Yes I agree that global lock allows only one thread to create/die (and so on) at any given moment, while suspend_disable/enable affect only suspension functionality. But in fact suspend_disable is per_thread lock for suspension, and if it's taken(suspend_disable called) other thread can't suspend particular thread while this lock is not released(suspend_enable called). And I believe that additional synchronization is excessive and very expensive. Also my opinion is that suspension scheme is the last place in DRLVM that should be changed w/o any open issue or problem which is depends on it (or we do have a problems in GC in regard to suspension). Do you really think that current scheme is unsafe and should be redesigned? Nik. - 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][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
I agree it is required to have a solid model in mind. I also believe it is required to have such design/implementation which doesn't allow to break that model. No, that's the point if functionality is so safe that it's impossible to break the model, it's not so highly important(as in our case) to understand how it works, this model will restore itself. It's ok to have safe points inside disabled regions only if it is really safe to enable GC at that point. All such cases should be taken with extreme caution. In our particular case we can't guarantee that it is safe to suspend the thread. That's why I think having something like assert(hythread_is_suspend_enabled) in the beginning of hythread_suspend_all is really required? Of cause it will require some changes in VM and TM... Again, I agree that sometimes safepoints enable suspension in wrong places an assert must be placed inside conditions, for instance, but suspend_all is the rare place where safe_point placed in suspend_disable region intentionally, by design(please refer to the lock semantics of safe regions in my answer to Weldon). Could you give the most impossible thing to do? Peace All Over the World? :) I was thinking of TM as of quite independent component. But now it seems like some parts of it are really depend on DRLVM implementation. :-( First of all, TM _is_ independent component, but some of its functions designed for special usage(it's potentially unsafe to nail up smth with the gun, for instance). Also, I believe that TM suspension safe enough an should not be rewritten w/o special need, and even if it should the performance of this functionality should be always in mind. Current suspension scheme was tested on multiple workloads and tuned to achieve better performance, and note that not even using additional locks but having CAS to perform suspend_disable/enable leads to noticeable performance loss. Actually my idea from the beginning is that while we don't have a scenario we should not change suspension algorithm. It's good enough, robust tuned for better performance of GC. Nik. - 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][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
Hello All, first of all I'd like to emphasize that suspend/resume_all functions are potentially unsafe and should be used with care. secondly, those methods were designed mainly to support stop_the_world_enumeration and thus usually being used under certain conditions. 1) I found that hythread_suspend_all calls thread_safe_point_impl inside. There is no assertion regarding thread's state upon entering hythread_suspend_all. So it can be called in suspend disabled state and nobody (at least me) expects to have a safe point during hythread_suspend_all. The problem seems to be very similar with the one discussed in [drlvm][threading] Possible race condition in implementation of conditional variables? Your thoughts? The code of suspend_all method is dedicated to the cyclic suspension problem. The fact that this method is being called from suspend_disable region and have safe_point in within is all about cyclic suspension. A lot of time was spent to resolve deadlocks cause by two threads trying to suspend each other. I agree that problem is similar to one with conditions, but I believe that this one should be discussed as a part of particular scenario. 2) Assume I need to suspend all threads in particular group. Ok I pass that group to hythread_suspend_all. Later when all suspended threads should be resumed I pass the same group to hythread_resume_all. But threads were suspended group has changed. For example one new thread was added to it. So the questions are. Is it acceptable to have such unsafe functionality? Would it better to lock the group in hythread_suspend_all and unlock it in hythread_resume_all. First of all I would differentiate j.l.ThreadGroup and thread groups defined by thread manager(saying that I mean that this method was not designed for ordinary use, like ThreadGroup.suspend()), and after that return to the question why we would need it (I mean, it would be better to have particular scenario) and then we can discuss how to implement this. Till now suspend_all method was designed to work within one group(in particular default group, containing java threads), and called be GC. Thank you. Nik. 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] - 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][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
The simplest model is to grab the thread lock whenever thread A wants to suspend thread B at a safepoint. While this serializes thread suspension and can potentially be a bottleneck, let's wait until its a proven performance problem to change this model. For thread A to be ready to grab the thread lock, thread A must have all its java live references put in a place where the GC will see them. Why? Because thread A may block. Once thread A obtains the lock, it can disable suspension if it likes, reload the java live refs and do whatever it needs but make certain it is quick and non blocking. If thread A needs to block on some OS call, etc, it will need to re-enable suspension and abandon the thread lock. Why? Because if thread A blocks while holding the global thread lock, there may be deadlock or latency problems. Did you try the above approach? ARe there deadlocks? I wonder if suspend_disable call can be treated as a thread lock and if yes we do have nearly the same scheme related to stop_the_world suspension. Nik. - 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?
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] 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
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: [testing][kernel.tests] j.l.Thread test fails on HARMONY-1582
I have finished running release build on WinXP, and I have following tests results: c_unit tests passed; smoke tests passed, but I have excluded gc.Los; kernel tests works with the 98.96 % success rate on all, jitrino.jet, opt and interpreter. Failing tests are: j.l.ObjectTest, j.l.RuntimeTest2, j.l.ThreadTest Thank you. Nik. On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: I'm running debug build on WinXP, and I have following results so far: c_unit tests passed; smoke tests passed except gc.Los which hangs as usual; kernel tests works with the following success rates: Jet : 98.96% Opt: 99.15% Int : still running Thank you. Nik. On 10/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok - I just committed 1582. Lets build on it... can someone test on winxp? I'll get to it in a bit, but would be happy to know sooner than later. Evgueni Brevnov wrote: Ok, I see. Then it should be TM problem right? On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Evgueni, according to the spec the thread wait method should throw interrupted exception even if it was interrupted before call. citing from the Object.wait method specification: Throws: InterruptedException - if another thread interrupted the current thread before or while the current thread was waiting for a notification. The interrupted status of the current thread is cleared when this exception is thrown. The same applicable, to the sleep and join methods. Thank you. Nik. On 10/9/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While testing HARMONY-1582 (invocation api) it turned out that one kernel test starts to fail with the following message: There were 3 failures: 1) testInterrupt_Joining(java.lang.ThreadTest)junit.framework.AssertionFailed Error: joining thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Joining(ThreadTest.java:1367) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 2) testInterrupt_Sleeping(java.lang.ThreadTest)junit.framework.AssertionFaile dError: sleeping thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Sleeping(ThreadTest.java:1390) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 3) testInterrupt_Waiting(java.lang.ThreadTest)junit.framework.AssertionFailed Error: waiting thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Waiting(ThreadTest.java:1413) at java.lang.reflect.VMReflection.invokeMethod(Native Method) FAILURES!!! Tests run: 89, Failures: 3, Errors: 0 Short investigation shows that test is invalid. Specifically main thread interrupts another thread and expects InterruptedException will be thrown while interruptable thread doesn't get to joining/sleeping/waiting state yet. Could somebody fix that 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] - 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: [testing][kernel.tests] j.l.Thread test fails on HARMONY-1582
Elena, thanks for the help, the problem discovered by ThreadTest explained in HARMONY-1789. Are you going to fix the issue or investigate test failures? Thank you. Nik. On 10/10/06, Elena Semukhina [EMAIL PROTECTED] wrote: I'm going to take care of j.l.ThreadTest. On 10/10/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: I have finished running release build on WinXP, and I have following tests results: c_unit tests passed; smoke tests passed, but I have excluded gc.Los; kernel tests works with the 98.96 % success rate on all, jitrino.jet, opt and interpreter. Failing tests are: j.l.ObjectTest, j.l.RuntimeTest2, j.l.ThreadTest Thank you. Nik. On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: I'm running debug build on WinXP, and I have following results so far: c_unit tests passed; smoke tests passed except gc.Los which hangs as usual; kernel tests works with the following success rates: Jet : 98.96% Opt: 99.15% Int : still running Thank you. Nik. On 10/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok - I just committed 1582. Lets build on it... can someone test on winxp? I'll get to it in a bit, but would be happy to know sooner than later. Evgueni Brevnov wrote: Ok, I see. Then it should be TM problem right? On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Evgueni, according to the spec the thread wait method should throw interrupted exception even if it was interrupted before call. citing from the Object.wait method specification: Throws: InterruptedException - if another thread interrupted the current thread before or while the current thread was waiting for a notification. The interrupted status of the current thread is cleared when this exception is thrown. The same applicable, to the sleep and join methods. Thank you. Nik. On 10/9/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While testing HARMONY-1582 (invocation api) it turned out that one kernel test starts to fail with the following message: There were 3 failures: 1) testInterrupt_Joining(java.lang.ThreadTest )junit.framework.AssertionFailed Error: joining thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Joining(ThreadTest.java:1367) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 2) testInterrupt_Sleeping(java.lang.ThreadTest )junit.framework.AssertionFaile dError: sleeping thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Sleeping(ThreadTest.java:1390) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 3) testInterrupt_Waiting(java.lang.ThreadTest )junit.framework.AssertionFailed Error: waiting thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Waiting(ThreadTest.java:1413) at java.lang.reflect.VMReflection.invokeMethod(Native Method) FAILURES!!! Tests run: 89, Failures: 3, Errors: 0 Short investigation shows that test is invalid. Specifically main thread interrupts another thread and expects InterruptedException will be thrown while interruptable thread doesn't get to joining/sleeping/waiting state yet. Could somebody fix that 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] - 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] -- Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED
Re: [testing][kernel.tests] j.l.Thread test fails on HARMONY-1582
I'm looking into this. Nik. On 10/10/06, Elena Semukhina [EMAIL PROTECTED] wrote: Nikolay, I thought that it was the problem in the test so I volunteered to fix it but now I see that this is hythread issue so please fix it asap! BTW, I see a lot of new classlib tests failures related to this bug. I updated H-1789 with instructions how to reproduce this. On 10/10/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Elena, thanks for the help, the problem discovered by ThreadTest explained in HARMONY-1789. Are you going to fix the issue or investigate test failures? Thank you. Nik. On 10/10/06, Elena Semukhina [EMAIL PROTECTED] wrote: I'm going to take care of j.l.ThreadTest. On 10/10/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: I have finished running release build on WinXP, and I have following tests results: c_unit tests passed; smoke tests passed, but I have excluded gc.Los; kernel tests works with the 98.96 % success rate on all, jitrino.jet, opt and interpreter. Failing tests are: j.l.ObjectTest, j.l.RuntimeTest2, j.l.ThreadTest Thank you. Nik. On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: I'm running debug build on WinXP, and I have following results so far: c_unit tests passed; smoke tests passed except gc.Los which hangs as usual; kernel tests works with the following success rates: Jet : 98.96% Opt: 99.15% Int : still running Thank you. Nik. On 10/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok - I just committed 1582. Lets build on it... can someone test on winxp? I'll get to it in a bit, but would be happy to know sooner than later. Evgueni Brevnov wrote: Ok, I see. Then it should be TM problem right? On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Evgueni, according to the spec the thread wait method should throw interrupted exception even if it was interrupted before call. citing from the Object.wait method specification: Throws: InterruptedException - if another thread interrupted the current thread before or while the current thread was waiting for a notification. The interrupted status of the current thread is cleared when this exception is thrown. The same applicable, to the sleep and join methods. Thank you. Nik. On 10/9/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While testing HARMONY-1582 (invocation api) it turned out that one kernel test starts to fail with the following message: There were 3 failures: 1) testInterrupt_Joining(java.lang.ThreadTest )junit.framework.AssertionFailed Error: joining thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Joining(ThreadTest.java :1367) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 2) testInterrupt_Sleeping(java.lang.ThreadTest )junit.framework.AssertionFaile dError: sleeping thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Sleeping(ThreadTest.java :1390) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 3) testInterrupt_Waiting(java.lang.ThreadTest )junit.framework.AssertionFailed Error: waiting thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Waiting(ThreadTest.java :1413) at java.lang.reflect.VMReflection.invokeMethod(Native Method) FAILURES!!! Tests run: 89, Failures: 3, Errors: 0 Short investigation shows that test is invalid. Specifically main thread interrupts another thread and expects InterruptedException will be thrown while interruptable thread doesn't get to joining/sleeping/waiting state yet. Could somebody fix that 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] - 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: [testing][kernel.tests] j.l.Thread test fails on HARMONY-1582
Evgueni, according to the spec the thread wait method should throw interrupted exception even if it was interrupted before call. citing from the Object.wait method specification: Throws: InterruptedException - if another thread interrupted the current thread before or while the current thread was waiting for a notification. The interrupted status of the current thread is cleared when this exception is thrown. The same applicable, to the sleep and join methods. Thank you. Nik. On 10/9/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While testing HARMONY-1582 (invocation api) it turned out that one kernel test starts to fail with the following message: There were 3 failures: 1) testInterrupt_Joining(java.lang.ThreadTest)junit.framework.AssertionFailed Error: joining thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Joining(ThreadTest.java:1367) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 2) testInterrupt_Sleeping(java.lang.ThreadTest)junit.framework.AssertionFaile dError: sleeping thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Sleeping(ThreadTest.java:1390) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 3) testInterrupt_Waiting(java.lang.ThreadTest)junit.framework.AssertionFailed Error: waiting thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Waiting(ThreadTest.java:1413) at java.lang.reflect.VMReflection.invokeMethod(Native Method) FAILURES!!! Tests run: 89, Failures: 3, Errors: 0 Short investigation shows that test is invalid. Specifically main thread interrupts another thread and expects InterruptedException will be thrown while interruptable thread doesn't get to joining/sleeping/waiting state yet. Could somebody fix that 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] - 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][kernel.tests] j.l.Thread test fails on HARMONY-1582
No it should not, but it is :). Look like there is no synchronization between setting interrupted flag and checking it, thus one may interrupt the thread between flag checking and actual wait, I will raise JIRA issue on this. Thank you. Nik. On 10/9/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Ok, I see. Then it should be TM problem right? On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Evgueni, according to the spec the thread wait method should throw interrupted exception even if it was interrupted before call. citing from the Object.wait method specification: Throws: InterruptedException - if another thread interrupted the current thread before or while the current thread was waiting for a notification. The interrupted status of the current thread is cleared when this exception is thrown. The same applicable, to the sleep and join methods. Thank you. Nik. On 10/9/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While testing HARMONY-1582 (invocation api) it turned out that one kernel test starts to fail with the following message: There were 3 failures: 1) testInterrupt_Joining(java.lang.ThreadTest)junit.framework.AssertionFailed Error: joining thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Joining(ThreadTest.java:1367) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 2) testInterrupt_Sleeping(java.lang.ThreadTest)junit.framework.AssertionFaile dError: sleeping thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Sleeping(ThreadTest.java:1390) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 3) testInterrupt_Waiting(java.lang.ThreadTest)junit.framework.AssertionFailed Error: waiting thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Waiting(ThreadTest.java:1413) at java.lang.reflect.VMReflection.invokeMethod(Native Method) FAILURES!!! Tests run: 89, Failures: 3, Errors: 0 Short investigation shows that test is invalid. Specifically main thread interrupts another thread and expects InterruptedException will be thrown while interruptable thread doesn't get to joining/sleeping/waiting state yet. Could somebody fix that 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] - 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: [testing][kernel.tests] j.l.Thread test fails on HARMONY-1582
I'm running debug build on WinXP, and I have following results so far: c_unit tests passed; smoke tests passed except gc.Los which hangs as usual; kernel tests works with the following success rates: Jet : 98.96% Opt: 99.15% Int : still running Thank you. Nik. On 10/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok - I just committed 1582. Lets build on it... can someone test on winxp? I'll get to it in a bit, but would be happy to know sooner than later. Evgueni Brevnov wrote: Ok, I see. Then it should be TM problem right? On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Evgueni, according to the spec the thread wait method should throw interrupted exception even if it was interrupted before call. citing from the Object.wait method specification: Throws: InterruptedException - if another thread interrupted the current thread before or while the current thread was waiting for a notification. The interrupted status of the current thread is cleared when this exception is thrown. The same applicable, to the sleep and join methods. Thank you. Nik. On 10/9/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While testing HARMONY-1582 (invocation api) it turned out that one kernel test starts to fail with the following message: There were 3 failures: 1) testInterrupt_Joining(java.lang.ThreadTest)junit.framework.AssertionFailed Error: joining thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Joining(ThreadTest.java:1367) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 2) testInterrupt_Sleeping(java.lang.ThreadTest)junit.framework.AssertionFaile dError: sleeping thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Sleeping(ThreadTest.java:1390) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 3) testInterrupt_Waiting(java.lang.ThreadTest)junit.framework.AssertionFailed Error: waiting thread has not received the InterruptedException at java.lang.ThreadTest.testInterrupt_Waiting(ThreadTest.java:1413) at java.lang.reflect.VMReflection.invokeMethod(Native Method) FAILURES!!! Tests run: 89, Failures: 3, Errors: 0 Short investigation shows that test is invalid. Specifically main thread interrupts another thread and expects InterruptedException will be thrown while interruptable thread doesn't get to joining/sleeping/waiting state yet. Could somebody fix that 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] - 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: [patch][drlvm] Linux/ia32 fix for Intel Compiler
Salikh,
out of curiosity, do you know why it happens that Intel Compiler
requires librt at build time to resolve symbols in run time, while gcc
works fine w/o this option.
Also parent system libset contains librt, but not being forwarded to
hythread (due to ant bug I believe), but if just copy parent libset to
hythread DRLVM will also crush at run time with another error, I
wonder why.
Thank you.
Nik.
On 10/4/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Hi,
DRLVM compiled with Intel Compiler 9.0 on Linux/ia32 currently
does not work due to symbol 'clock_gettime' not being found.
A simple build file fix is needed to solve the problem.
It does not affect DRLVM built with gcc.
(Gcc build still works with this modification).
Could anyone commit this change?
Thanks a lot!
--- a/build/make/components/vm/hythr.xml
+++ b/build/make/components/vm/hythr.xml
@@ -95,6 +95,7 @@ vm.port,extra.log4cxx, extra.aprutil /
/select
select os=lnx
+syslibset libs=rt /
linkerarg value=-Wl,-init /
linkerarg value=-Wl,hythread_library_init /
linkerarg
value=-Wl,--version-script,${src}/thread/src/hythr.exp /
-
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][thread] Thread.currentThread() is not alive anymore :(
Fixed, patch submitted to JIRA. Thread constructor used to initialize main thread simply didn't set alive status. This patch also corrects main thread's name and sets context class loader to SystemClassLoader. Thank you. Nik. On 9/22/06, Elena Semukhina [EMAIL PROTECTED] wrote: Kernel test ThreadTest fails due to Thread.currentThread().isAlive() returns false now. I've created a JIRA issue for this problem. https://issues.apache.org/jira/browse/HARMONY-1537 Does anyone want to study the issue and submit a patch for it? -- Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] getting activeMQ to run
Hello,
I was able to run ActiveQM on Linux with patch attached. Looks like
something is broken in logger static initialization sequence. Though
this patch helpps in running ActiveQM, I would treat this patch as
workaround, this issue requires some more analysis and testing.
Nik.
On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Sep 22, 2006, at 12:47 AM, Vladimir Gorr wrote:
On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Sep 22, 2006, at 12:37 AM, Vladimir Gorr wrote:
On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Even though we have the jar issue fixed w/t he launcher-based
build,
I still can't run ActiveMQ using release build on Ubuntu.
Can anyone else report success? Or a patch? :)
I was succesfull on Windows. No success exist for Linux however.
What do you see on linux?
ACTIVEMQ_HOME: /nfs/ins/proj/drl/coreapi/vgorr/Tools/incubator-
activemq-4.0
Loading message broker from: xbean:activemq.xml
ERROR: java.lang.RuntimeException: Failed to execute start task.
Reason:
org.springframework.beans.factory.BeanCreationException: Error
creating bean
with name 'org.apache.activemq.store.PersistenceAdapterFactoryBean'
defined
in class path resource [activemq.xml]: Instantiation of bean failed;
...
Yah, that's what I get. We really need to get this kind of thing
worked out, and fast...
geir
snipped
...
Steps I do are the following:
1. unset JAVA_HOME
2. set PATH=.../jre/bin;PATH
3. cd .../activemq-3.2.3\bin; activemq
Are these steps correct?
Close enough. I set JAVA_HOME to the harmony jre directory (deploy/
jre), added bin to the path, and then
sh bin/activemq
But I'm using activeMQ 4.0.something
Yes, it seems this version doesn't work correctly. At least on Linux.
I'll try this on Windows as well.
Thanks,
Vladimir.
Thanks,
Vladimir.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: modules/logging/src/main/java/java/util/logging/LogManager.java
===
--- modules/logging/src/main/java/java/util/logging/LogManager.java
(revision 448895)
+++ modules/logging/src/main/java/java/util/logging/LogManager.java
(working copy)
@@ -197,7 +197,13 @@
// if global logger has been initialized, set
root as its parent
Logger root = Logger.getLogger(); //$NON-NLS-1$
-Logger.global.setParent(root);
+Logger global = Logger.global;
+
+if (Logger.global == null) {
+global = Logger.getLogger(global);
+}
+
+global.setParent(root);
return null;
}
});
-
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] getting activeMQ to run
core dumps in debug and prints something like this in release: WARN DefaultJDBCAdapter - Could not create JDBC tables; they could already exist. Failure was: That might be simply because you created the tables needed when you ran the first time? I don't know for sure, but J9 works fine w/o any warnings: INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /nfs/pb/home/nakuznet/disk_j/workspace/harmony.orig/incubator-activemq-4.0.1/activemq-data/journal ... ... and the fact that debug version core dumps, also looks suspicious :) Nik. , but finally starts: INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:pbtmrte007-57413-1158949586838-1:0) started Will continue investigate. So this look ok... My tests w/ the patch show it running, and I was able to run producer/ consumer tests geir Nik. On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: First, thanks so much for the fast response and good solution. I don't see any problem with this patch, but you're right - I don't understand why we have it, since Logger should set it's global field to getLogger(global) in the static initialization. I have the same problem with J9, so I don't think it's a VM problem. If no one complains, I'm going to test it, apply it, and add a JIRA to look at the fact that global isn't set...or tell me why it shouldn't be geir On Sep 22, 2006, at 1:51 PM, Nikolay Kuznetsov wrote: Hello, I was able to run ActiveQM on Linux with patch attached. Looks like something is broken in logger static initialization sequence. Though this patch helpps in running ActiveQM, I would treat this patch as workaround, this issue requires some more analysis and testing. Nik. On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 22, 2006, at 12:47 AM, Vladimir Gorr wrote: On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 22, 2006, at 12:37 AM, Vladimir Gorr wrote: On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Even though we have the jar issue fixed w/t he launcher- based build, I still can't run ActiveMQ using release build on Ubuntu. Can anyone else report success? Or a patch? :) I was succesfull on Windows. No success exist for Linux however. What do you see on linux? ACTIVEMQ_HOME: /nfs/ins/proj/drl/coreapi/vgorr/Tools/incubator- activemq-4.0 Loading message broker from: xbean:activemq.xml ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.store.PersistenceAdapterFactoryBean' defined in class path resource [activemq.xml]: Instantiation of bean failed; ... Yah, that's what I get. We really need to get this kind of thing worked out, and fast... geir snipped ... Steps I do are the following: 1. unset JAVA_HOME 2. set PATH=.../jre/bin;PATH 3. cd .../activemq-3.2.3\bin; activemq Are these steps correct? Close enough. I set JAVA_HOME to the harmony jre directory (deploy/ jre), added bin to the path, and then sh bin/activemq But I'm using activeMQ 4.0.something Yes, it seems this version doesn't work correctly. At least on Linux. I'll try this on Windows as well. Thanks, Vladimir. Thanks, Vladimir. geir - Terms of use : http://incubator.apache.org/harmony/ mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] LogManager.patch - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL
Re: [classlib][launcher][drlvm] Running vm inside gdb
Yes, I've seen the same, please keep us informed if you find a solution. On 9/23/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: GNU gdb 6.4 Attaching is ok, but it is not quite convinient to do attaching when running small test, I prefer: gdb --args prog args... but it no longer works for me after switch to new launcher. -- Ivan On 9/23/06, Sunny Chan [EMAIL PROTECTED] wrote: Which version of gdb are you using? Older version of gdb doesn't play along well with nptl or java launcher which spawn another process. Try running your java program first and attach gdb to the process. Ivan Volosyuk wrote: I have problems running drlvm from gdb: (gdb) run Starting program: /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/java Test [Thread debugging using libthread_db enabled] [New Thread -1214326592 (LWP 25698)] [New Thread -1214510160 (LWP 25701)] Cannot find user-level thread for LWP 25698: generic error Does anybody have seen the problem? -- 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] - 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] getting activeMQ to run
Ok then, it was suse 9, ia32. On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: what platform? I'm not seeing that... On Sep 22, 2006, at 4:01 PM, Nikolay Kuznetsov wrote: core dumps in debug and prints something like this in release: WARN DefaultJDBCAdapter - Could not create JDBC tables; they could already exist. Failure was: That might be simply because you created the tables needed when you ran the first time? I don't know for sure, but J9 works fine w/o any warnings: INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /nfs/pb/home/nakuznet/disk_j/workspace/harmony.orig/incubator- activemq-4.0.1/activemq-data/journal ... ... and the fact that debug version core dumps, also looks suspicious :) Nik. , but finally starts: INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:pbtmrte007-57413-1158949586838-1:0) started Will continue investigate. So this look ok... My tests w/ the patch show it running, and I was able to run producer/ consumer tests geir Nik. On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: First, thanks so much for the fast response and good solution. I don't see any problem with this patch, but you're right - I don't understand why we have it, since Logger should set it's global field to getLogger(global) in the static initialization. I have the same problem with J9, so I don't think it's a VM problem. If no one complains, I'm going to test it, apply it, and add a JIRA to look at the fact that global isn't set...or tell me why it shouldn't be geir On Sep 22, 2006, at 1:51 PM, Nikolay Kuznetsov wrote: Hello, I was able to run ActiveQM on Linux with patch attached. Looks like something is broken in logger static initialization sequence. Though this patch helpps in running ActiveQM, I would treat this patch as workaround, this issue requires some more analysis and testing. Nik. On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 22, 2006, at 12:47 AM, Vladimir Gorr wrote: On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 22, 2006, at 12:37 AM, Vladimir Gorr wrote: On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Even though we have the jar issue fixed w/t he launcher- based build, I still can't run ActiveMQ using release build on Ubuntu. Can anyone else report success? Or a patch? :) I was succesfull on Windows. No success exist for Linux however. What do you see on linux? ACTIVEMQ_HOME: /nfs/ins/proj/drl/coreapi/vgorr/Tools/ incubator- activemq-4.0 Loading message broker from: xbean:activemq.xml ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.store.PersistenceAdapterFactoryBean' defined in class path resource [activemq.xml]: Instantiation of bean failed; ... Yah, that's what I get. We really need to get this kind of thing worked out, and fast... geir snipped ... Steps I do are the following: 1. unset JAVA_HOME 2. set PATH=.../jre/bin;PATH 3. cd .../activemq-3.2.3\bin; activemq Are these steps correct? Close enough. I set JAVA_HOME to the harmony jre directory (deploy/ jre), added bin to the path, and then sh bin/activemq But I'm using activeMQ 4.0.something Yes, it seems this version doesn't work correctly. At least on Linux. I'll try this on Windows as well. Thanks, Vladimir. Thanks, Vladimir. geir - Terms of use : http://incubator.apache.org/harmony/ mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/ mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] LogManager.patch
Re: [classlib][regex] Is this a issue of java.util.regex.Matcher.region(int, int);
Hello Spark Shen, It seems that Matcher.region(int, int) will not have any effects when called. This can be demonstrated by the following test case there is an issue quite similar to one you have raised filled by Richard: http://issues.apache.org/jira/browse/HARMONY-759 I'll try to provide a fix today, thanks for reminding. BTW, there are other issues about java.util.regex. If necessary, can we disscuss all these issues case by case. Surely, we can discuss issues if needed, but if smth just does not work, please fill an issue in JIRA, I'm looking after regex issues. If you need some problems to fix urgently, let me know separately. Yours sincerely, Nik. - 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] Created: (HARMONY-696) Harmony regex does not support Character.isXXX character classes
Richard,
We have two issues here:
[688] java.util.regex.Matcher does not support Unicode supplementary characters
[696] Harmony regex does not support Character.isXXX character classes
I would prefer, if you don't mind, to fix them separately. I know that
supplementary character support is a tricky thing and will take some
time while {java} char. classes could be fixed relatively
quick(w/o supplementary character support).
And I have a question, am I right that supplementary character affects
mostly ranges and character classes all the other constructs will work
fine w/o special processing, what do you think.
Thank you.
Nik.
On 6/29/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello Nik,
Just a kind reminder, as you may already know, a set of new is
methods have been defined since Java 1.5 which have a int (codepoint)
parameter. This may make things tricky. ;-)
Best regards,
Richard.
-
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] Created: (HARMONY-696) Harmony regex does not support Character.isXXX character classes
Unfortunately, I can provide some test cases to demonstrate other
constructs, such as X{n}, DO support supplementary characters. But I'm
not sure if other constructs need special processing.
OK, I see, I'll provide general support for supplementary characters,
instead of patching some special functionality like character classes,
thanks for the clue.
And if you'll update regex unit tests with test cases that would be great.
BTW, what's DO?
-
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] Requirement: Regex support for \p{javaDigit}
Hello Richard,
Thanks for pointing this out. While implementing java character
classes I missed the fact that _all_ Character.isXXX methods except
deprecated should have corresponding \\p{javaXXX} character class
analogues. So the the answer to your question whether we should
implement javaDigit char class is YES.
I've opened an issue to support the rest of character classes:
http://issues.apache.org/jira/browse/HARMONY-696
Also, thanks a lot for your willing to add javaDigit class, but if you
don't mind I would implement full range of {javaXXX} classes by myself
just because it would be easier for me, as for an author :-).
Hopefully, I'll be ready with this tomorrow.
On 6/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello All,
I'm trying to implement java.util.Scanner.nextInt, which requires a
regular expression pattern to represent Integer. I find it's hard to
express /NonASCIIDigit /because now Harmony regex does not support
/NonASCIIDigit/.
As our regex has supported \p{javaLowerCase} Equivalent to
java.lang.Character.isLowerCase(), to facilitate the development of
j.u.Scanner, shall we provide support for \p{javaDigit}, which is
equivalent to java.lang.Character.isDigit()? I could provide patch for
this feature if there is no objection. Thanks lot.
*
*You may want to refer to the number syntax in java.util.Scanner Spec:*
*/QUOTE
NonASCIIDigit :: = A non-ASCII character c for which
Character.isDigit(c) returns true
Non0Digit ::= [1-Rmax] | NonASCIIDigit
Digit ::= [0-Rmax] | NonASCIIDigit
GroupedNumeral :: = ( Non0Digit Digit? Digit? ( LocalGroupSeparator
Digit Digit Digit )+ )
Numeral ::= ( ( Digit+ ) | GroupedNumeral )
Integer ::= ( [-+]? ( Numeral ) ) | LocalPositivePrefix Numeral
LocalPositiveSuffix | LocalNegativePrefix Numeral LocalNegativeSuffix/
//QUOTE/
--
Richard Liang
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: [jira] Created: (HARMONY-606) java.util.regex.Pattern fails to compile some patterns
Hello Richard, Thank you for this find. For some reason I've missed these character classes. Will update JIRA issue in a moment. -- Regards, Nikolay Kuznetsov, 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-350) HARMONY-39 Regular expressions does not match backreferences during find.
Done. Nikolay, please provide a single patch that resolves the problem 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]
Re: EOL differences in svn diffs
Yes, I saw that too, and I agree that it makes it virtually impossible to see exactly what was changed. I used a windows machine to apply your patch and commit the code, so I can only assume that's why the file was converted to DOS EOL. I'll poke around to see if I can make it preserve the incoming EOL convention. Subversion manual suggests the following: The solution to this problem is the svn:eol-style property. When this property is set to a valid value, Subversion uses it to determine what special processing to perform on the file so that the file's line ending style isn't flip-flopping with every commit that comes from a different operating system. The valid values are: native/CR/LF/CRLF, However, I tried to play with this switch on local machine (svn client/local svn server) and this had no effect. Currently I'm preparing next patch for regular expressions and it's become a bit complicated (not too much, though:)). One has to preserve line endings for particular file in patches, otherwise patch will not work. Regards, Nik
Re: EOL differences in svn diffs
Actually, you need to set 2 properties: svn:mime-type : text/plain svn:eol-style : native It depends a lot from the svn client, though. I tried this, but in my case files are returning from repository in the format they are stored in repository. Thanks a lot for the comment, I'll try to use another client. Regards, Nik
Re: NullPointerException
I have reminiscence that the general rule is that unless otherwise stated methods and constructors will throw NPE if passed null argument. Unfortunately I have not found more general place in javadoc stating this except following citing from java.util.logging package description: In general, unless otherwise noted in the javadoc, methods and contructors will throw NullPointerException if passed a null argument. The one broad exception to this rule is that the logging convenience methods in the Logger class (the config, entering, exiting, fine, finer, finest, log, logp, logrb, severe, throwing, and warning methods) will accept null values for all arguments except for the initial Level argument (if any). I understand this as that in general methods and constructors do not check if arguments passed are null or not, otherwise javadoc specifies the exact behavior. Of course there are exceptions which are not stated in javadoc, but those exceptions should be checked on case by case basis. Also I think that exact checks for null arguments are not necessary (except those cases when they have special meaning) and moreover could cause performance impact. -- Nikolay Kuznetsov, Intel Middleware Products Division
Re: Platform dependent code placement (was: Re: repo layout again)
Hello, team,
I've tried to simplify construction below, which is sample of Andrey's
ant script, and end up with following regular expression which matches
string containing particular OS identifier or strings w/o any OS
identifiers:
.*([_\\W]${env.OS}[_\\W].*$|.*(?!.*[\\W_](win|lin|sol)[\\W_].*)$)
This would work fine with regex package from HARMONY-39 contribution,
but fail to compile with SUN's classes (PatternSyntaxException:
Look-behind group does not have an obvious maximum length, I would
appreciate if someone point me to the place in any regex
specification, stating that it's valid behavior).
From the compatibility point of view this enhancement is no good, but
to give a hint how to implement negative assertions in terms of regex
negative look behind/ahead is the solution.
propertyregex property=OS.match input=@{file}
regexp=[\W_]${env.OS}[\W_] override=yes defaultValue=no
select=yes/
propertyregex property=OS.any.match input=@{file}
regexp=[\W_](win|linux|solaris)[\W_] override=yes
defaultValue=no select=yes/
istrue value=${OS.match}/
not
istrue value=${OS.any.match}/
/not
Thank you.
Nikolay Kuznetsov
Intel Middleware Products Division
