sablevm-developer Mailing List for SableVM (Page 26)
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer — SableVM developer mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(27) |
Aug
(22) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(30) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(32) |
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(69) |
Sep
(10) |
Oct
(31) |
Nov
(15) |
Dec
(58) |
| 2003 |
Jan
(33) |
Feb
(81) |
Mar
(85) |
Apr
(24) |
May
(15) |
Jun
(14) |
Jul
(6) |
Aug
(9) |
Sep
(101) |
Oct
(59) |
Nov
(142) |
Dec
(34) |
| 2004 |
Jan
(107) |
Feb
(164) |
Mar
(181) |
Apr
(96) |
May
(81) |
Jun
(71) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chris P. <chr...@ma...> - 2004-01-20 01:17:36
|
>> 6) Can you think of anything to do with class initialization, object >> finalization, or native method calls that would cause problems with >> what I'm describing? As in, problems that I won't detect safely? >> I'm asking about non-speculative parent threads, with or without >> children, executing these sections, possibly forking children. >> Speculative instructions are themselves safe with respect to global >> memory, exception handling, GC, native methods, and code preparation. > > > Let's be nasty... What if the parent thread creates a Thread instance and > calls Thread.start()? I guess this implies a native call and is thus > covered > in your approach, right? > > I guess you have to worry about native methods. A native method should > probably invalidate speculative children. > > That's all that comes to my mind. I don't think the Thread.start() example is a problem. If a speculative thread tries to start a new thread, it will hit a native method call and abort. If a non-speculative thread without spmt children tries to start a new thread, it can do so. Then we have two non-speculative threads, each of which can start speculative children of their own. If a non-speculative thread with spmt children tries to start a new thread, then if that thread violates some dependences the children will be aborted. In any case, the call to the method that started the thread should return normally, and thus reach the join point before the abortion occurs. Basically ... I am worried about having: FORK (jump over invoke and execute past join speculatively) INVOKE (executed non-speculatively in parallel) JOIN and the INVOKE not returning to the JOIN point (e.g. by throwing an exception) or the initial "speculative" stack at the JOIN being incorrect (e.g. because of GC). Additionally, if the INVOKE can somehow affect the data specific to the speculative thread (not global data), that would be something I need to know about. Note that I am not currently planning for speculative threads to run in their own Java Thread, but rather be clones of the non-speculative parent (and thus be invisible to other non-speculative threads and their children), running in a pthread that I manage explicitly. (it's not necessary to get sidetracked into the multithreading details at this point). Anyway, let me know if a problem in my reasoning occurs to you at some point (Clark too!), and meanwhile I'm just going to go ahead and implement this, based off of your previous answers and the latest description I gave. Thanks again, Chris |
|
From: Etienne G. <gag...@uq...> - 2004-01-19 23:54:23
|
Chris Pickett wrote:
> Now, summarized:
>
> 1a) If I mark relevant threads for GC being called at line 418 in
> thread.c, will this catch them all?
It does visit all "live" threads. SableVM was designed so that dead
thread data structures can be recycled for new threads, lowering the
pressure on the memory manager [malloc/free in this case].
>
> 1b) If I put the code to abort speculative children because the
> non-speculative parent threw an exception, natively or not, at line 364
> in interpreter.c, will this catch everything?
Yes (I think).
> 6) Can you think of anything to do with class initialization, object
> finalization, or native method calls that would cause problems with what
> I'm describing? As in, problems that I won't detect safely? I'm asking
> about non-speculative parent threads, with or without children,
> executing these sections, possibly forking children. Speculative
> instructions are themselves safe with respect to global memory,
> exception handling, GC, native methods, and code preparation.
Let's be nasty... What if the parent thread creates a Thread instance and
calls Thread.start()? I guess this implies a native call and is thus covered
in your approach, right?
I guess you have to worry about native methods. A native method should
probably invalidate speculative children.
That's all that comes to my mind.
> Thank-you very very much. I apologize if any of this seems exceedingly
> obvious to you, but I made some incorrect assumptions in the past and I
> want to prevent that this time around (I've disabled almost everything
> and am turning features on one at a time).
No, it's not obvious at all, even to me. It's just that you face two
competing yet important goals, when you write to me and want an answer:
1- You must explain things very clearly (and unambiguously) and provide
enough information so that I can actually answer.
2- You must write a short ( < 10 lines ) message so that, if I have a 2-5 minutes
hole in my schedule, I will be tempted to read it and answer. Otherwise, it
ends up on the stack of hundreds of messages I hope to have time some day
to answer. [You might notice that I do sometime answer such emails, but after
a few months...] Unless, of course, you don't need the answer any time soon. :-)
> P.S. In the future, I would like to help design and possibly implement
> some kind of high-level CFG for the VM, which is (partially) built from
> directives in the source. Discussions like this and the GC one make me
> think about stuff like that.
Let's finish the speculative stuff first! And if you have time to spare, you
could help with the general infrastructure (e.g. getting Eclipse to run on
SableVM, etc.) :-)))
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
|
|
From: Etienne G. <gag...@uq...> - 2004-01-19 23:36:38
|
David B=E9langer wrote: > I looked quickly. The only change that require some work is the split > of Runtime into VMRuntime/Runtime. It should not be difficult and > should not take time. I could have staging updated tonight or tomorrow= =2E Super. > So, that means next term we merge, we will need to use a revision > number. It would not be better to use tag like cvs-yyyy-mm-dd, althoug= h > technically revision number do not cause problem? Not really. Revisions numbers are quite sufficient, in this case. We mi= ght do such updates quite regularly; adding tags won't help at all. In fact, th= ey would obscure the important tags. [I think along the lines of: "would you tag every staging revision?"] --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Chris P. <chr...@ma...> - 2004-01-19 23:00:05
|
Hi Etienne, Thanks kindly for your response. I've compressed the unanswered bits for you at the end, and tried to cut out as much as possible. >> 3) Am I correct to assume that the "speculative" stack obtained after >> jumping over a method call will not differ from the actual stack when >> that point is reached non-speculatively? > > > Which stack? The operand stack, or the Java stack? > The entire Java stack, which includes the operand stack. I am getting errors where portions of the Java stack differ if I compare a saved Java stack (that was generated by skipping over a void method and popping parameters) with the actual stack. My plan is to keep track of a) _svmf_interpreter() depth b) height of the current frame on the Java stack c) whether an exception is thrown in the skipped method d) whether GC is called in the skipped method to determine when I have actually returned (and can thus join the speculative thread). Ignore the bit about safety of speculative instructions in the original question -- it doesn't apply to the problem of determining join points. > Do not forget about _svmf_ensure_stack_capacity() which can actually > change the "absolute" location of the Java stack (and thus the absolute > location of the operand stack). Right, I'm sure that this is not the problem, the comparison is value-by-value between saved and actual stacks. ========== Now, summarized: 1a) If I mark relevant threads for GC being called at line 418 in thread.c, will this catch them all? 1b) If I put the code to abort speculative children because the non-speculative parent threw an exception, natively or not, at line 364 in interpreter.c, will this catch everything? 6) Can you think of anything to do with class initialization, object finalization, or native method calls that would cause problems with what I'm describing? As in, problems that I won't detect safely? I'm asking about non-speculative parent threads, with or without children, executing these sections, possibly forking children. Speculative instructions are themselves safe with respect to global memory, exception handling, GC, native methods, and code preparation. Thank-you very very much. I apologize if any of this seems exceedingly obvious to you, but I made some incorrect assumptions in the past and I want to prevent that this time around (I've disabled almost everything and am turning features on one at a time). Cheers, Chris P.S. In the future, I would like to help design and possibly implement some kind of high-level CFG for the VM, which is (partially) built from directives in the source. Discussions like this and the GC one make me think about stuff like that. |
|
From: David <db...@cs...> - 2004-01-19 22:17:49
|
On Mon, Jan 19, 2004 at 03:28:15PM -0500, Etienne Gagnon wrote: > David B=E9langer wrote: > >You mean getting most recent CP changes? Yes. > >Look in mailing list archives, I think Etienne described > >how to do it. I think Etienne needs to add them to > >some branch. >=20 > OK. I have imported a CP CVS snapshot to /sablevm-classpath/vendor/cur= rent=20 > . >=20 Hi, I looked quickly. The only change that require some work is the split of Runtime into VMRuntime/Runtime. It should not be difficult and should not take time. I could have staging updated tonight or tomorrow. > As it is not an official CP release, I have not added a tag for it in > sablevm-classpath/vendor/tags . >=20 So, that means next term we merge, we will need to use a revision number. It would not be better to use tag like cvs-yyyy-mm-dd, although technically revision number do not cause problem? David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Etienne G. <gag...@uq...> - 2004-01-19 21:49:53
|
Chris, some answers below. Chris Pickett wrote: > 2) Do all calls to _svmf_interpreter() end in INTERNAL_CALL_END (it > appears this way from invoke_interface.c)? No. They can also end: - at line 636 of interpreter.c: initializing the interpreter. - at line 400 of interpreter.c: exception path. > 3) If I keep track of _svmf_interpreter() call depth and Java call > depth, abort speculative children on GC or exceptions in the parent > non-speculative thread, and abort speculative children on global > memory-writing (Java heap or not) instructions in the speculative child, > am I correct to assume that the "speculative" stack obtained after > jumping over a method call will not differ from the actual stack when > that point is reached non-speculatively? Which stack? The operand stack, or the Java stack? Do not forget about _svmf_ensure_stack_capacity() which can actually change the "absolute" location of the Java stack (and thus the absolute location of the operand stack). > 4) Can I furthermore assert that the next instruction to be executed > after a method call has completed, in the absence of an exception being > thrown in the call, is the next instruction in the code array? Yes. > 5) Do calls to _svmf_interpreter() enter and exit cleanly? In other > words, am I right to assume that there is nothing like a Java exception > that can occur to screw up control flow, and that when the height of the > call stack returns you are back where you started? _svmf_interpreter sets a longjump handler, so it never exits other than through "return" (at one of 3 identified locations: 2 above + INTERNAL_CALL_END) as far as I remember. -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-19 21:48:35
|
W liście z pon, 19-01-2004, godz. 16:21, David Bélanger pisze: > Hi Greg, > > I implemented but did not test any of them. The only thing > I did is to make sure it compiles without warning. > > Therefore, they will be in my sandbox instead of staging: > svn+ssh://svn.sablevm.org/public/developers/belanger/sandbox/sablevm > > Feel free to test and move them to staging if you are confident they > work. Some time later I will move them to staging but don't know > when. You're fast! great! I think the right approach is to find apps that fail w/ staging because of lack of some of these JNI functions, then add them and the app should get further. I think that things like Eclipse would excersise many of these functions :-) Heh, we'll see how it goes in practice. Cheers, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
|
From: David <db...@cs...> - 2004-01-19 21:21:18
|
Hi Greg, I implemented but did not test any of them. The only thing I did is to make sure it compiles without warning. Therefore, they will be in my sandbox instead of staging: svn+ssh://svn.sablevm.org/public/developers/belanger/sandbox/sablevm Feel free to test and move them to staging if you are confident they work. Some time later I will move them to staging but don't know when. The functions implemented: GetSuperclass IsAssignableFrom Throw FatalError DeleteGlobalRef IsSameObject AllocObject IsInstanceOf David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Etienne G. <gag...@uq...> - 2004-01-19 21:08:42
|
David B=E9langer wrote: > There are a few JNI functions such as GetSuperClass, IsAssignableFrom > that have most functionality implemented in the reflection native meth= ods. > I will borrow the implementation for now but eventually, we may want > to factor out this functionality and reorganize the code. At some point, we might want to carefully look at both the JNI & reflecti= on stuff. Ideally, reflection would use JNI functions when available, so th= at a VM would only need to implement JNI to get as much as reflection functi= onal. But, we must first find out if it is possible, because of the side effect= s that can be triggered or not by the various methods/functions (e.g. class initialization, etc). Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne G. <gag...@uq...> - 2004-01-19 21:08:41
|
David B=E9langer wrote: >>From my understanding of global refs, *obj cannot be NULL in correct co= de > as null is represented by obj =3D=3D NULL. Is there any > situation that *obj could be NULL? I think that it is possible, because I do "pre-allocate" global refs for static fields, which are NULL by default. On the other hand, I think it would be a correct assumption that JNI code= cannot create such global refs. If you wish to remove it, please add an assertion, e.g.: assert (obj =3D=3D NULL || *obj !=3D NULL); Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne G. <gag...@uq...> - 2004-01-19 20:55:03
|
Chris,
Your messages are too long. I'm sincerely sorry, but I have to ask to su=
mmarize.
I'll try to answer the summary as well as I can.
Etienne
Chris Pickett wrote:
> Hi Etienne,
>=20
> I looked into bootstrapping and class loading (tracing execution with=20
> M-. and M-* in etags) and realized that the problems I'm having are due=
=20
> to my assumption that when the env->stack.current_frame offset reaches =
> the same height again, the method has returned, when in fact that metho=
d=20
> may have called _svmf_interpreter() somewhere along the line, and=20
> although the height of the current_frame in the Java stack may be=20
> correct, the height in the C stack is incorrect.
>=20
> So ... my questions are ...
>=20
> 1) Does the indented stuff below (sorry Greg for the "AOL-style" email)=
=20
> make sense w.r.t. exceptions and GC? In other words, have I identified=
=20
> the unique entry points for exceptions and GC correctly, and am I=20
> correct to assume that GC or exceptions as caused by native code will=20
> pass through these points?
>=20
> 2) Do all calls to _svmf_interpreter() end in INTERNAL_CALL_END (it=20
> appears this way from invoke_interface.c)?
>=20
> 3) If I keep track of _svmf_interpreter() call depth and Java call=20
> depth, abort speculative children on GC or exceptions in the parent=20
> non-speculative thread, and abort speculative children on global=20
> memory-writing (Java heap or not) instructions in the speculative child=
,=20
> am I correct to assume that the "speculative" stack obtained after=20
> jumping over a method call will not differ from the actual stack when=20
> that point is reached non-speculatively?
>=20
> 4) Can I furthermore assert that the next instruction to be executed=20
> after a method call has completed, in the absence of an exception being=
=20
> thrown in the call, is the next instruction in the code array?
>=20
> 5) Do calls to _svmf_interpreter() enter and exit cleanly? In other=20
> words, am I right to assume that there is nothing like a Java exception=
=20
> that can occur to screw up control flow, and that when the height of th=
e=20
> call stack returns you are back where you started?
>=20
> 6) Do you see any reason, if I take care of things like described above=
,=20
> that I would need to worry about non-speculatively executing native=20
> methods, class initializers, or finalizers, possibly with speculative=20
> children before starting or possibly forking new speculative children i=
n=20
> each of these (native methods might call JNI functions that start=20
> speculative threads)?
>=20
> If the answer to any of these is "no" or "maybe", I don't need a long=20
> explanation as much as pointers to the relevant code (I can ask=20
> questions later if I don't understand it).
>=20
> Cheers,
> Chris
>=20
>=20
>=20
> Chris Pickett wrote:
>=20
>>
>>
>> David B=E9langer wrote:
>>
>>> On Sat, Jan 17, 2004 at 12:21:30AM -0500, Chris Pickett wrote:
>>> =20
>>>
>>>> So ... can somebody explain (3) for me? Can native code affect=20
>>>> stack values or control flow without going through the=20
>>>> exception_handler: in interpreter.c or going through=20
>>>> _svmf_stop_the_world? If so, where does it do it?
>>>> =20
>>>
>>>
>>> Look at NATIVE_STATIC_METHOD and NATIVE_NONSTATIC_METHOD.
>>>
>>> All the code to unwind the stack is in _svmf_interpreter. Though the=
>>> exception object is built by the native method or one of the
>>> method/function it calls.
>>>
>>> =20
>>>
>> that's what i thought. i had changed _svmf_interpreter() to:
>>
>> athrow_handler:
>> ...
>> abstractmethoderror_handler:
>> exception_handler:
>> <my code to flag exceptions / kill speculative children is here=
>
>>
>> <normal exception handler stuff>
>>
>> and i don't understand how an exception can be thrown natively or=20
>> non-natively without passing by "exception_handler:" in=20
>> _svmf_interpreter ...
>>
>>> GC is usually trigger by creating new instance and not enough memory.=
>>> There is also a native method that forces gc.
>>> Java_java_lang_Runtime_gc. There is a single gc entry point that wil=
l
>>> stop all threads (except the current one) before doing the actual gc.=
>>> Look in gc_copying.c.
>>>
>>> =20
>>>
>>
>> okay, i had assumed that _svmf_stop_the_world was always called and=20
>> always visited all threads for each gc, whether gc is called natively =
>> or not. I had changed _svmf_stop_the_world() in thread.c to:
>>
>> /* visit all threads */
>> for (...)
>> {
>> jboolean succeeded;
>> <my code to flag gc is here>
>>
>> if (current =3D=3D env)
>> ...
>> }
>>
>> and I still don't understand how GC could be called without passing=20
>> through this code for each thread. after looking at=20
>> Java_java_lang_Runtime_gc, i see that it calls=20
>> _svmf_copy_gc_no_exception(), which in turn calls _svmf_stop_the_world=
=20
>> ...
>=20
>=20
>=20
>=20
>=20
--=20
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
|
|
From: Etienne G. <gag...@uq...> - 2004-01-19 20:46:37
|
David B=E9langer wrote: > You mean getting most recent CP changes? Yes. > Look in mailing list archives, I think Etienne described > how to do it. I think Etienne needs to add them to > some branch. OK. I have imported a CP CVS snapshot to /sablevm-classpath/vendor/curre= nt . As it is not an official CP release, I have not added a tag for it in sablevm-classpath/vendor/tags . Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David <db...@cs...> - 2004-01-19 20:09:29
|
Hi,
In the current NewGlobalRef, I see:
if (obj =3D=3D NULL || *obj =3D=3D NULL)
{
goto end;
}
From my understanding of global refs, *obj cannot be NULL in correct code
as null is represented by obj =3D=3D NULL. Is there any
situation that *obj could be NULL?
If not, I could change it to:
if (obj =3D=3D NULL) {
goto end;
}
David
---
David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226
Web page: http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt
|
|
From: David <db...@cs...> - 2004-01-19 19:59:09
|
Hi, There are a few JNI functions such as GetSuperClass, IsAssignableFrom that have most functionality implemented in the reflection native methods= . I will borrow the implementation for now but eventually, we may want to factor out this functionality and reorganize the code. ok? David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Chris P. <chr...@ma...> - 2004-01-19 19:39:47
|
Hi Etienne,
I looked into bootstrapping and class loading (tracing execution with=20
M-. and M-* in etags) and realized that the problems I'm having are due=20
to my assumption that when the env->stack.current_frame offset reaches=20
the same height again, the method has returned, when in fact that method =
may have called _svmf_interpreter() somewhere along the line, and=20
although the height of the current_frame in the Java stack may be=20
correct, the height in the C stack is incorrect.
So ... my questions are ...
1) Does the indented stuff below (sorry Greg for the "AOL-style" email)=20
make sense w.r.t. exceptions and GC? In other words, have I identified=20
the unique entry points for exceptions and GC correctly, and am I=20
correct to assume that GC or exceptions as caused by native code will=20
pass through these points?
2) Do all calls to _svmf_interpreter() end in INTERNAL_CALL_END (it=20
appears this way from invoke_interface.c)?
3) If I keep track of _svmf_interpreter() call depth and Java call=20
depth, abort speculative children on GC or exceptions in the parent=20
non-speculative thread, and abort speculative children on global=20
memory-writing (Java heap or not) instructions in the speculative child, =
am I correct to assume that the "speculative" stack obtained after=20
jumping over a method call will not differ from the actual stack when=20
that point is reached non-speculatively?
4) Can I furthermore assert that the next instruction to be executed=20
after a method call has completed, in the absence of an exception being=20
thrown in the call, is the next instruction in the code array?
5) Do calls to _svmf_interpreter() enter and exit cleanly? In other=20
words, am I right to assume that there is nothing like a Java exception=20
that can occur to screw up control flow, and that when the height of the =
call stack returns you are back where you started?
6) Do you see any reason, if I take care of things like described above, =
that I would need to worry about non-speculatively executing native=20
methods, class initializers, or finalizers, possibly with speculative=20
children before starting or possibly forking new speculative children in =
each of these (native methods might call JNI functions that start=20
speculative threads)?
If the answer to any of these is "no" or "maybe", I don't need a long=20
explanation as much as pointers to the relevant code (I can ask=20
questions later if I don't understand it).
Cheers,
Chris
Chris Pickett wrote:
>
>
> David B=E9langer wrote:
>
>>On Sat, Jan 17, 2004 at 12:21:30AM -0500, Chris Pickett wrote:
>> =20
>>
>>>So ... can somebody explain (3) for me? Can native code affect stack =
>>>values or control flow without going through the exception_handler: in=
=20
>>>interpreter.c or going through _svmf_stop_the_world? If so, where doe=
s=20
>>>it do it?
>>> =20
>>>
>>
>>Look at NATIVE_STATIC_METHOD and NATIVE_NONSTATIC_METHOD.
>>
>>All the code to unwind the stack is in _svmf_interpreter. Though the
>>exception object is built by the native method or one of the
>>method/function it calls.
>>
>> =20
>>
> that's what i thought. i had changed _svmf_interpreter() to:
>
> athrow_handler:
> ...
> abstractmethoderror_handler:
> exception_handler:
> =20
> <my code to flag exceptions / kill speculative children is here>
>
> <normal exception handler stuff>
>
> and i don't understand how an exception can be thrown natively or=20
> non-natively without passing by "exception_handler:" in=20
> _svmf_interpreter ...
>
>>GC is usually trigger by creating new instance and not enough memory.
>>There is also a native method that forces gc.
>>Java_java_lang_Runtime_gc. There is a single gc entry point that will
>>stop all threads (except the current one) before doing the actual gc.
>>Look in gc_copying.c.
>>
>> =20
>>
>
> okay, i had assumed that _svmf_stop_the_world was always called and=20
> always visited all threads for each gc, whether gc is called natively=20
> or not. I had changed _svmf_stop_the_world() in thread.c to:
>
> /* visit all threads */
> for (...)
> {
> jboolean succeeded;
> =20
> <my code to flag gc is here>
>
> if (current =3D=3D env)
> ...
> }
>
> and I still don't understand how GC could be called without passing=20
> through this code for each thread. after looking at=20
> Java_java_lang_Runtime_gc, i see that it calls=20
> _svmf_copy_gc_no_exception(), which in turn calls _svmf_stop_the_world =
=2E..
|
|
From: Etienne G. <gag...@uq...> - 2004-01-19 18:47:29
|
David B=E9langer wrote: > You mean getting most recent CP changes? Yes. > Look in mailing list archives, I think Etienne described > how to do it. I think Etienne needs to add them to > some branch. OK. I'll pull the latest CP changes into sablevm-classpath/vendor/current= . Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne G. <gag...@uq...> - 2004-01-19 18:43:53
|
Etienne Gagnon wrote: > Hmmm, I should be able to get the VM to print a stack trace fairly easily. OK. It's in staging. -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne G. <gag...@uq...> - 2004-01-19 15:43:43
|
Grzegorz B. Prokopski wrote: > $ bugwatcher > [jni: fatal error (Local reference capacity exceeded)] > Aborted > > (btw: shouldn't we give a stack backtrace at this point? > it's not really helpful as this way it's hard to say > where the problem actually can be) Hmmm, I should be able to get the VM to print a stack trace fairly easily. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David <db...@cs...> - 2004-01-19 15:28:23
|
On Mon, Jan 19, 2004 at 05:40:54AM -0500, Grzegorz B. Prokopski wrote:
> Hi!
>=20
> I've just tried to run things from debbuggtk and there's important
> improvement - it almost starts now. After a while I get:
>=20
> $ bugviewer=20
> (java-gnome:6261): Gtk-CRITICAL **: file gtkwidget.c: line 3690
> (gtk_widget_grab_default): assertion `GTK_WIDGET_CAN_DEFAULT (widget)'
> failed
> [jni: fatal error (Local reference capacity exceeded)]
> Aborted
>=20
> $ bugwatcher=20
> [jni: fatal error (Local reference capacity exceeded)]
> Aborted
>=20
Hi Greg,
The VM has to guarantee the availability of some amount of local refs
(I think 16). If local or not freed or a call to a special method
to increment them is not done, the VM does not have to guarantee
the availability. It was discussed before.
So possible it is in the user code.
> (btw: shouldn't we give a stack backtrace at this point?
> it's not really helpful as this way it's hard to say
> where the problem actually can be)
>=20
> I am not sure whether this problem is in java-gnome itself or
> rather in GNU Classpath, but I believe I have seen some mails
> on GNU CP ML lately, that were about not using more local
> references than allowed.
>=20
> Or maybe somebody has a better idea where the problem could be?
gdb
setup a brk point on where that message is printed then
bt - for your backtrace
>=20
> Anyway - can we synchronize our SVN w/ current upstream?
> Is there any documentation how to do this properly?
>=20
You mean getting most recent CP changes? Yes.
Look in mailing list archives, I think Etienne described
how to do it. I think Etienne needs to add them to
some branch.
Merge should be easy as most recent changes should not affect
VM/Classpath interfaces.
> We should also start pushing our changes back upstream.
>=20
Feel free to proceed. I already pushed a few=20
bug fixes by mailing patches on classpath mailing list.
If someone wants to work on that intensively, maybe request CP cvs write
access and contact CP on the procedure.
The next thing I would like to push is my fork/exec/Process
implementation as soon as it get more or less complete/tested
as it has nothing to do with the VM...
There would also be all the VM{Classes} that needs proper integration.
And should move some of our change upstream.
> sablevm: INTERNAL ERROR (source file "native_interface.c", line 23026):
> todo
> it's AllocObject (JNIEnv *_env, jclass cls) - so maybe it could be
> the next hole to target.
>=20
ok. It should be easy. Will do it sometime this afternoon.
David
---
David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226
Web page: http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt
|
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-19 10:40:59
|
Hi! I've just tried to run things from debbuggtk and there's important improvement - it almost starts now. After a while I get: $ bugviewer (java-gnome:6261): Gtk-CRITICAL **: file gtkwidget.c: line 3690 (gtk_widget_grab_default): assertion `GTK_WIDGET_CAN_DEFAULT (widget)' failed [jni: fatal error (Local reference capacity exceeded)] Aborted $ bugwatcher [jni: fatal error (Local reference capacity exceeded)] Aborted (btw: shouldn't we give a stack backtrace at this point? it's not really helpful as this way it's hard to say where the problem actually can be) I am not sure whether this problem is in java-gnome itself or rather in GNU Classpath, but I believe I have seen some mails on GNU CP ML lately, that were about not using more local references than allowed. Or maybe somebody has a better idea where the problem could be? Anyway - can we synchronize our SVN w/ current upstream? Is there any documentation how to do this properly? We should also start pushing our changes back upstream. Cheers, Grzegorz B. Prokopski PS: Trying to run bugreporter I get sablevm: INTERNAL ERROR (source file "native_interface.c", line 23026): todo it's AllocObject (JNIEnv *_env, jclass cls) - so maybe it could be the next hole to target. -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-19 08:47:03
|
W liście z pon, 19-01-2004, godz. 02:14, David Bélanger pisze: > On Sat, Jan 17, 2004 at 03:18:23PM -0500, Grzegorz B. Prokopski wrote: > > BTW: I tried to run bugview from debbuggtk package and I got this: > > sablevm: INTERNAL ERROR (source file "native_interface.c", line 23281): > > todo > > which is caused by a call to > > GetObjectArrayElement (JNIEnv *_env, jobjectArray array, jsize indx) > svn up > I implemented it recently... and it is in staging. Ah, great! I'll try it soon, then :-) > > hmm... more than 10 functions around this one are just stubs. It doesn't > > look very good. Any chaces to get them filled in w/ real code? > Several are trivial to implement. However, to test them take some > time... Let's make a deal then: you implement them and I (with help from other users) test them (trial by fire ;-) Cheers! Grzegorz B. Prokopski -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
|
From: Patrick C. <er...@ps...> - 2004-01-19 07:32:41
|
Also sprach Grzegorz B. Prokopski zu "17.01.2004 11:08" Anno Domini:
> W liście z sob, 17-01-2004, godz. 04:17, David Bélanger pisze:
>
>>Hi,
>>
>>I think it would be great if SableVM could be built out-of-the-box on
>>all platforms including the non-Linuxian FreeBSD and OS X. It will
>>simplify my life as I want to build and test on these platforms.
>>Currently source code is not an issue, it is more a configure/Makefile
>>isssue.
>>
>>src/libsablevm/Makefile.am has some line like:
>>libsablevm_la_LIBADD = -lpthread -lm -lffi -lltdl -lrt
>>
>>FreeBSD does not like -lpthread.
>>OS X does not like -lrt.
>>
>>This is because functionnality is located elsewhere and there are
>>no such libXX.so file... (Actually, on OS X, there is a single
>>libSystem that includes implementation of libc, libm, libpthread and
>>probably others. libc etc. are only symlinks to libSystem. But there
>>are no librt symlinks in the default installation)
>>
>>A long time ago, I had:
>>if REQ_LPTHREAD
>>REQ_LIBS = -lpthread -lm -lffi -lltdl -lrt
>>else
>>REQ_LIBS = -lc_r -lm -lffi -lltdl -lrt
>>endif
>>libsablevm_la_LIBADD = ${REQ_LIBS}
>>
>>where REQ_LPTHREAD was set in ./configure.ac.
>>
>>This was ok for FreeBSD but will become more complex with -lrt on/off.
>>Note: I tried first with simpler things but automake/conf tools didn't
>>like it. There are some restriction of what the right hand side arg
>>of libsablevm_la_LIBADD can be for the autoconf/make tools, don't
>>remember which one.
>
>
> svn diff -r 1204:HEAD \
> svn://svn.sablevm.org/developers/mlord/sandbox/sablevm-staging |less
>
> will show you what was changed for cygwin port (not yet merged)
> It also didn't like -lrt (only Solaris requires it apparently)
> but it wasn't solved nicely.
>
> But if we take a look at these parts:
>
> +++ configure.ac (revision 1385)
> +dnl defining macro (platform_win32) only for Cygwin or Mingw
> +AC_MSG_CHECKING([for some Win32 platform])
> +
> +case "$host" in
> + *-*-mingw*|*-*-cygwin*)
> + platform_win32=yes
> + ;;
> + *)
> + platform_win32=no
> + ;;
> +esac
> +AC_MSG_RESULT([$platform_win32])
> +AM_CONDITIONAL(PLATFORM_WIN32, test "$platform_win32" = "yes")
> +
> +++ src/libsablevm/Makefile.am (revision 1385)
> +if PLATFORM_WIN32
> +no_undefined = -no-undefined
> +endif
> +
> [...]
> +libsablevm_la_LDFLAGS = -version-info @LIBRARY_VERSION@ $(no_undefined)
>
> One could add detection of other platforms in configure.ac and
> accordignly add in makefiles ex.
> +if PLATFORM_SOLARIS
> +lrt=-lrt
> +endif
> and so on...
>
> But I don't think I like this stuff, first because it'd require us to
> create PLATOFORM_* defines for maaaany platforms, second - this config
> info (what to link with or not) looks like global stuff, so why would
> it reside in one Makefile.am and not in the other one(s)? We should
> save ourselves coding and do maximum of it in one place (configure),
> while minimizing changes in other places (Makefiles).
>
> Ideally, I think we'd have in configure.ac sth. like:
> +AC_MSG_CHECKING([if we need -no-undefined])
> +
> +case "$host" in
> + *-*-mingw*|*-*-cygwin*)
> + no_undefined=-no-undefined
> + AC_MSG_RESULT([yes])
> + ;;
> + *)
> + AC_MSG_RESULT([no])
> + ;;
> +esac
>
> +AC_MSG_CHECKING([if we need -lrt])
> +
> +case "$host" in
> + *solaris*)
> + lrt=-lrt
> + AC_MSG_RESULT([yes])
> + ;;
> + *)
> + AC_MSG_RESULT([no])
> + ;;
> +esac
>
> +AC_MSG_CHECKING([if we need -lpthread])
> +
> +case "$host" in
> + *freebsd*)
> + AC_MSG_RESULT([no])
> + ;;
> + *)
> + lpthread=-lpthread
> + AC_MSG_RESULT([yes])
> + ;;
> +esac
>
> (system id strings, besides cygwin/mingw should probably be narowed)
>
> and then use @no_undefined@, @lrt@ and @lpthread@ in Makefiles - where
> needed. They either would contain respective params or be empty.
That's exactly what you should do in configure! For that reason, there
are more macros provided by autoconf that only "AC_MSG_*". Your last
case for example could be simpliefied to a simple one-liner using
AC_CHECK_LIB! Have a look at the autoconf info pages for a complete
overview. A call of autoscan in your sources could also be helpful (have
a look at the generated configure.scan template). On Debian, there
exists a package named autobook with a quiet complete html documentation
about auto*. Last but not least, three pointers:
http://seul.org/docs/autotut/
http://www.amath.washington.edu/~lf/tutorials/autoconf/
http://nis-www.lanl.gov/~rosalia/mydocs/autoconf_tutorial_toc.html
Hope this help!
CU
--
Patrick Cernko | mailto:er...@er... | http://www.errror.de
Quote of the Week: "Quis custodit custodes?
Ceterum censeo Microsoftem esse delendam!"
(anonyum)
|
|
From: David <db...@cs...> - 2004-01-19 07:14:40
|
On Sat, Jan 17, 2004 at 03:18:23PM -0500, Grzegorz B. Prokopski wrote: >=20 > BTW: I tried to run bugview from debbuggtk package and I got this: >=20 > sablevm: INTERNAL ERROR (source file "native_interface.c", line 23281): > todo >=20 > which is caused by a call to > GetObjectArrayElement (JNIEnv *_env, jobjectArray array, jsize indx) > svn up I implemented it recently... and it is in staging. > hmm... more than 10 functions around this one are just stubs. It doesn'= t > look very good. Any chaces to get them filled in w/ real code? >=20 Several are trivial to implement. However, to test them take some time... I could implement several of them but it will have low priority. So that means, they will get slowly but eventually done. David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Etienne G. <gag...@uq...> - 2004-01-18 22:07:08
|
Archie Cobbs wrote: > The reasoning is simple: pending_halt_thread_count only counts threads > that are running in Java mode. When it reaches zero, you consider the > world halted, yet there may very well be threads running in native mode > that had already entered native mode when stop_the_world() was called > (and so they didn't count in the pending_halt_thread_count total). This is exacly what we want. Do you have any idea when a native thread might call back into the VM (e.g. either the call ends, or some JNI function is called)? I don't. In fact, the native thread might be sleeping or into some kind of almost infinite loop. We definitely don't want GC to wait for such thread. > So if that's the case, then my idea of allowing halting threads to enter > native mode should not be adding any bugs that aren't already there. > Am I making any sense? :-) Yes and no. We would have to change the state diagram and make sure we have not introduced a bug somewhere else. In the state diagram, there is no direct transition from SVM_THREAD_STATUS_HALT_REQUESTED to SVM_THREAD_STATUS_NOT_RUNNING_JAVA_RESUMING_DISALLOWED. OK. This is all hypothetical stuff. Let stop it here. Etienne PS: Of course, it would be awesome if somebody gave his notes to Chris for transcription. :-) Thanks for the offer, Chris. -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Archie C. <ar...@de...> - 2004-01-18 21:44:46
|
Archie Cobbs wrote: > > > However, I don't think this really gives you much advantage. It lets > > > a thread continue in native mode instead of halting, but it probably > > > is not going to get much further before having to come back to java mode > > > and then halt anyway. Just a thought experiment really. > > > > Theoretically, it could quite possibly work (I would have to think carefully > > about all corner cases, but there's no deep reason it wouldn't work), but > > practically, I don't see much benefit. Current code simply depends on > > the well tested _svmf_halt_if_requested(). Adding custom code for such critical > > and difficult to write correctly code (even though it is short, it is very > > tricky) is not something I look forward to. :-) > > I hear you :-) Simplicity is sometimes it's own reward.. Actually I forgot to mention my original thought. I think the following statement is true: If it is not safe to let halting threads enter native mode, then SableVM currently has a bug. The reasoning is simple: pending_halt_thread_count only counts threads that are running in Java mode. When it reaches zero, you consider the world halted, yet there may very well be threads running in native mode that had already entered native mode when stop_the_world() was called (and so they didn't count in the pending_halt_thread_count total). So if that's the case, then my idea of allowing halting threads to enter native mode should not be adding any bugs that aren't already there. Am I making any sense? :-) Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Halloo Communications * http://www.halloo.com |
6 messages has been excluded from this view by a project administrator.
