Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On 10/25/06, Pavel Afremov <[EMAIL PROTECTED]> wrote: Good idea Mikhail! I think I will base on it in my future solution. I see only one negative side for it. Quantity of the treads increased by one in normal situation. Any ideas? the only idea I have is to spawn N threads at once if final

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Good idea Mikhail! I think I will base on it in my future solution. I see only one negative side for it. Quantity of the treads increased by one in normal situation. Any ideas? Thanks. Pavel Afremov. On 10/25/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: The "Work Balance Subsystem" tas

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

The "Work Balance Subsystem" task is to start new finalizing threads when all active threads are busy, isn't it? The solution could be: 1) Add +1 thread: "finalizers manager" 2) notify this thread (as Salikh proposed) to start finalization and do the "Work Balance Subsystem" job. Does it work or

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

No. It couldn't. I don't now any solution which can do it. Pavel Afremov. On 10/25/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: On 10/25/06, Pavel Afremov <[EMAIL PROTECTED]> wrote: > > Your fix just switch off Finalization Work Balance Subsystem Pavel, could Work Balance Subsystem be impl

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On 10/25/06, Pavel Afremov <[EMAIL PROTECTED]> wrote: Your fix just switch off Finalization Work Balance Subsystem Pavel, could Work Balance Subsystem be implemented in finilizers threads directly. That is we will not have Java code executed from helpers? -- Mikhail Fursov

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Hi The source code of the gc tests don't initiate circularity error directly. It's unclear side effect, because error happen during VM start up time. In this case additional printing for example can "fix" the bug. So I agree with Gregory that tests shouldn't be changed in this situation in spite

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On 10/24/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: Yes, the lock is global. I used try_enter() to prevent possible deadlock scenario, when the finalization happens at precisely the moment finalization thread is holding the finalization lock. If this happens, and vm_hint_finalize() cannot gra

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Gregory Shimansky wrote: > On Tuesday 24 October 2006 19:20 Salikh Zakirov wrote: >> I would like to request for comments on a possible way of getting rid >> of java execution from vm_hint_finalize(). The initial patch is attached to >> HARMONY-1952. > > You've also modified the problematic test i

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On Tuesday 24 October 2006 19:20 Salikh Zakirov wrote: > I would like to request for comments on a possible way of getting rid > of java execution from vm_hint_finalize(). The initial patch is attached to > HARMONY-1952. You've also modified the problematic test in it. Are you sure this modificat

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Pavel Afremov wrote: > gc.Finalizer and gc PhantomReferenceQueueTest are synthetic test. And can't > be called "normal" (do code review, if you doubt, please). But this test > isn't source of the circularity error. The error can happen for usual > application too. The CL an SM tests just show that

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Salikh, gc.Finalizer and gc PhantomReferenceQueueTest are synthetic test. And can't be called "normal" (do code review, if you doubt, please). But this test isn't source of the circularity error. The error can happen for usual application too. The CL an SM tests just show that source of fake circ

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Salikh, On 10/24/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: And Pavel's synthetic tests (HARMONY-1945) do something allowed by the spec, but entirely uncommon for an application -- recursive call from a classloader to the application. Which spec do you mean? The test crashes BEA but AFAIK

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Gregory Shimansky wrote: > Yes the test is synthetic. But the whole problem arose from the currently > excluded smoke tests gc.PhantomReferenceQueueTest and gc.Finalizer. They too > are synthetic but may be an example of another place where this problem > appears. > > The idea to write user cod

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On Tuesday 24 October 2006 15:50 Alex Astapchuk wrote: > Lazy resolution is not a silver bullet, and it's even a question whether > it will help in these tests. > > If Bea passes the test, then I presume there are no such tests in TCK, > so this will not affect [possible further] compatibility test

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Mikhail Fursov wrote: Pavel, thanks SUN passes both tests (with -Xcomp too), BEA(1.5) crashes as expected.Our VM throws ClassCircularityError with both compilers and passes with interpreter. IMO we must add lazy resolution to both compilers in future. The reason: to Hmm... this particular 'mu

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

> I hope we all understand the same under "lazy resolution" but it would be >> better if you explained a bit how it is going to work. >> > > Let's ask Alex Astapchuk to describe it. He tried to do it in JET, so he > knows more nuances about implementation problems. > Currently, both .opt and .jet

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On 10/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: On Tuesday 24 October 2006 12:32 Mikhail Fursov wrote: > Pavel, thanks > SUN passes both tests (with -Xcomp too), BEA(1.5) crashes as expected.Our I wonder why it is expected :) I tried very similar test some time ago. So it's OK that

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On Tuesday 24 October 2006 12:32 Mikhail Fursov wrote: > Pavel, thanks > SUN passes both tests (with -Xcomp too), BEA(1.5) crashes as expected.Our I wonder why it is expected :) > VM throws ClassCircularityError with both compilers and passes with > interpreter. > IMO we must add lazy resolution

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Pavel, thanks SUN passes both tests (with -Xcomp too), BEA(1.5) crashes as expected.Our VM throws ClassCircularityError with both compilers and passes with interpreter. IMO we must add lazy resolution to both compilers in future. The reason: to be able to run everything SUN runs. The question is w

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Ok. I've created *HARMONY-1945*. You can find tests here. BR. Pavel Afremov On 10/23/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: Pavel, I see no attachment.. ? On 10/23/06, Pavel Afremov <[EMAIL PROTECTED]> wrote: > > Hi > > > > I've deve

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On Monday 23 October 2006 22:05 Mikhail Fursov wrote: > Pavel, I see no attachment.. ? I think Geir has commented on this once. Apache mail list filters some types of attachments away (IIRC to keep all intellectual property clean from code taken from unknown code sources). To make some files pub

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Pavel, I see no attachment.. ? On 10/23/06, Pavel Afremov <[EMAIL PROTECTED]> wrote: Hi I've developed two "impossible" tests, which shows "fake" circularity errors. One test is more simple and use SecurityManager. The other is a bit more complex and uses custom ClassLoader. You can find the

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Hi   I've developed two "impossible" tests, which shows "fake" circularity errors. One test is more simple and use SecurityManager. The other is a bit more complex and uses custom ClassLoader. You can find them in attachment.   Thanks. Pavel Afremov On 10/17/06, Pavel Pervov <[EMAIL PROTECTED]> wr

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

The scenario I described earlier is impossible. Resolution of any class referenced in some other class is performed by class loader, which loaded that other class. So, no chance to load "A" and referencing class loader (UCL) with this UCL. Sorry for confusion. Regards, Pavel. P.S. Still ther

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

IMO we shall be between BEA and SUN: to work if both RI work, to fail if both RI fail and discuss each test in details if only one RI passes. On 10/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: On Friday 13 October 2006 08:04 Alexey Varlamov wrote: > I'm curious, if we enable "controlled"

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On Friday 13 October 2006 08:04 Alexey Varlamov wrote: > I'm curious, if we enable "controlled" recursion in classloading - > will it resolve this kind of issues completely? I'm pretty sure it > would resolve at least some scenarios - like the one Pavel described > for gc.Finalizers or a case of cl

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On 10/13/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: On Thursday 12 October 2006 14:06 Mikhail Fursov wrote: > On 10/12/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > Yes, lazy (interpreter style) resolution will solve the problem - JIT > > will never ask to load classes while compiling. >

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

13.10.06, Gregory Shimansky<[EMAIL PROTECTED]> написал(а): On Thursday 12 October 2006 14:06 Mikhail Fursov wrote: > On 10/12/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > Yes, lazy (interpreter style) resolution will solve the problem - JIT > > will never ask to load classes while compiling. >

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On Thursday 12 October 2006 14:06 Mikhail Fursov wrote: > On 10/12/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > Yes, lazy (interpreter style) resolution will solve the problem - JIT > > will never ask to load classes while compiling. > > Here we have different vision. What do you think, is it po

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On 10/12/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: Yes, lazy (interpreter style) resolution will solve the problem - JIT will never ask to load classes while compiling. Here we have different vision. What do you think, is it possible to go into the endless resursion with lazy resolution? I

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Mikhail, The problem is not in locking any resources (Alexey Varlamov discovered another error - in kernel classes natives). The problem is in recursive loading of the same class twice. Yes, lazy (interpreter style) resolution will solve the problem - JIT will never ask to load classes while comp

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On the 0x200 day of Apache Harmony Pavel Pervov wrote: > Mikhail, > > Unfortunately, both our compilers are affected by this issue. fixing only JET sounds more or less realistic. Fixing OPT is an overkill. Pavel, that would have been great if we had some real tests to go on with fixing. As usua

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

I'm glad to hear this part of the problem is resolved :) Some thoughts for the initial test from Pavel: We do really need the Java test to discuss. I still think that the problem you desribe is not a JIT problem. Yes, both JET and OPT ask to resolve classes during compilation. When they do it the

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On 10/12/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: Yes, I am. :) The common rule of not executing Java under native lock applies to JNI too. Especially, if you hold VM internal lock. Regards, Pavel. On 10/12/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > 12.10.06, Pavel Pervo

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Yes, I am. :) The common rule of not executing Java under native lock applies to JNI too. Regards, Pavel. On 10/12/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: 12.10.06, Pavel Pervov<[EMAIL PROTECTED]> написал(а): > Alexey, > > The main issue here is why classloading (?) calls to GC under

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

12.10.06, Pavel Pervov<[EMAIL PROTECTED]> написал(а): Alexey, The main issue here is why classloading (?) calls to GC under native lock. All the rest is just a consequences. Could you, please, show the point (file:line) where gc_alloc is called under lock? Oh, probably you are right. The fault

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Alexey, The main issue here is why classloading (?) calls to GC under native lock. All the rest is just a consequences. Could you, please, show the point (file:line) where gc_alloc is called under lock? Thanks, Pavel. On 10/12/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: Guys, I've fou

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On 10/12/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: 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 scenari

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Mikhail, Unfortunately, both our compilers are affected by this issue. Pavel. On 10/11/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: 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

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On 10/12/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: 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. AFAIK, it is possible to run Sun's Hotspot VM with o

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

Guys, I've found another deadlock scenario recently, see HARMONY-1833 [1]: "deadlocks happening between main thread (MT) and finalizer thread (FT): 1) MT performs classloading, it grabs ClassLoader::_lock; 2) GC happens, FinalizerThread.startFinalization() is called, FT activates; 3) FT invokes

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) J

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

On Wednesday 11 October 2006 18:18 Mikhail Fursov wrote: > 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 method

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* On 10/9/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrot

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

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

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)

[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 so

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 exa

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* On 10/9/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I get this more often than not

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]> wro

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 finali

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)

Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable

On Wednesday 11 October 2006 04:19 Xiao-Feng Li wrote: > Yes, I agree. > > This is related to the issue I found in bootstrapping JVM. Since DRLVM > is largely written in C (C++) and partially written in Java, the > bootstrapping process should be more clearly to avoid this kind of > bug. That is al

Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable

Yes, I agree. This is related to the issue I found in bootstrapping JVM. Since DRLVM is largely written in C (C++) and partially written in Java, the bootstrapping process should be more clearly to avoid this kind of bug. That is all the system level code that are written in Java probably can be

Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable

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 bei

Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable

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 (an

[drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable

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: