sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] On the 1.1.1 release and further

[Etienne G. <gag...@uq...>]

Chris Pickett wrote:
> I think 1.2 beta is too much ...

Agreed.

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] On the 1.1.1 release and further

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

> Hi all,
> 
> I wanted to ask you for opinions and suggestions about how and when
> should SableVM 1.1.1 release happend. Below you'll find what I think
> about it, given our last experiences with 1.1.0 and current state of the
> affairs. I also touch some further issues. Even if you (accidentally)
> agree with the below, I'd love to hear it.
> 
> SableVM 1.1.1 release objectives:
> * Fixes of grave bugs since 1.1.0 (like waitfor())
> * Enchancements since 1.1.0
>   - new classpath 0.08 (soon to be released)
>   - David's fillings in the JNI interface
>   - Thread.interrupt() and (if I make it on time) EnsureLocalCapacity()
> * Get more attention as our conficence in 1.1.1 is bigger (announces
>   on sablevm-announce, freshmeat, etc. - should we call it "1.2 beta?")

I think 1.2 beta is too much ... 1.2 will only come when Etienne has 
time to review the code (and I'm guessing May at the earliest).

> SableVM 1.1.1 release path (based on what worked for us before):
> 1. Importing new Classpath release
> 2. Merging new Classpath into staging
> 3. Testing the codebase
> 4. Making and announcing the release
> 
> Last time 1) was done by Etienne, 2) by David, 3) by Chris,  4) by me.
> I think that besides some side issues and bad timing caused by things
> beyond our influence, it worked pretty well, so it'd be great, if this
> time also everyone could put his share in the process.  (I'd be
> particularly interested in helping with 2), but only if I have
> interrupt() and EnsureLocalCapacity() done by that time)

I can do (3) again, but I want to get a paper finished first.  I am 
aiming for the end of March at the moment.  Also, it would be nice at 
some point to merge a few my changes into staging (possibly even all of 
those that are used in the paper?), but I don't mind if this waits until 
after 1.1.1.

Cheers,
Chris

[Sablevm-developer] prepare_code.m4.c format request

[Chris P. <chr...@ma...>]

Hi,

I would like to request in advance a format for prepare_code.m4.c that 
will minimize changes against the prepare_code.m4.c in my sandbox.

I know there are a few ways to do things.  I've been using the following 
when only certain portions of a file need be m4'ed.

Cheers,
Chris

============================================

/* m4svm_file_name */      <---- 1st line of file
/* m4svm_on(0)m4_dnl */

...

/* some comment *[::]/
    m4svm_off ();
*/

m4svm_define_begin v = ":], [:m4svm_macro_name:])";

...

m4svm_define_end v = ":])";
/* m4svm_macro_name(arg1,arg2,...,argN)
    m4_undefine([:m4svm_macro_name:])
    m4svm_on(0)m4_dnl */

...

EOF

Re: [Sablevm-developer] On the 1.1.1 release and further

[David <db...@cs...>]

On Wed, Mar 10, 2004 at 01:53:34PM -0500, Grzegorz B. Prokopski wrote:
> Hi all,
>=20
> I wanted to ask you for opinions and suggestions about how and when
> should SableVM 1.1.1 release happend. Below you'll find what I think
> about it, given our last experiences with 1.1.0 and current state of th=
e
> affairs. I also touch some further issues. Even if you (accidentally)
> agree with the below, I'd love to hear it.
>=20
> SableVM 1.1.1 release objectives:
> * Fixes of grave bugs since 1.1.0 (like waitfor())
> * Enchancements since 1.1.0
>   - new classpath 0.08 (soon to be released)
>   - David's fillings in the JNI interface
>   - Thread.interrupt() and (if I make it on time) EnsureLocalCapacity()
> * Get more attention as our conficence in 1.1.1 is bigger (announces
>   on sablevm-announce, freshmeat, etc. - should we call it "1.2 beta?")
>=20
> SableVM 1.1.1 release path (based on what worked for us before):
> 1. Importing new Classpath release
> 2. Merging new Classpath into staging
> 3. Testing the codebase
> 4. Making and announcing the release
>=20
> Last time 1) was done by Etienne, 2) by David, 3) by Chris,  4) by me.
> I think that besides some side issues and bad timing caused by things
> beyond our influence, it worked pretty well, so it'd be great, if this
> time also everyone could put his share in the process.  (I'd be
> particularly interested in helping with 2), but only if I have
> interrupt() and EnsureLocalCapacity() done by that time)
>=20

Hello,

#2 is usually quite straightforward if nothing changes in the classes
interfacing CP with SableVM.

However, some {VM,}Classes are kind of not super well intergrated,
especially VMThread/Thread and class loader related class.

The thing is that Etienne did several changes including fixes.  These
changes, done on a very old CP, were more or less transfered to our
newer CP.  I removed some of Etienne code when it was obvious the CP was
now complete for these.  However for some tricky parts such as class
loading and thread related, when unsure, I opted for Etienne's version.

Ideally, we would need to "merge" properly CP and Etienne version for
the CP code.  Currently it is more or less, some methods are CP, others
are Etienne's etc.

> Another thing is SableJIT release. It's up to David when it happens,
> but I think we shouldn't wait too long with releasing this code as a
> _development_ release. We can even do it along 1.1.1, why not? I think
> that this way David (and we all) could get some bugreports from the
> users or/and gain confidence that SableJIT is actually usable in
> the real, wild world ;-) And for some people word "JIT" is magical...

If you want, it could be added eventually.  It is still
underdevelopment but a SableVM compiled with the JIT code is still able
to run in interpreter-only mode.  In that case the JIT is never
initialized and not used and this should not make sablevm unstable.

I worked not so long ago on decreasing the diff between the staging.

What would be the approach of integrating this.  I think Etienne did a
SableJIT/staging branch quite some time ago.

SableJIT has 2 components, some C glue code that must be compiled with
SableVM and some Java code.

The C code is mostly located in libsablevm/sablejit but also at several
places in SableVM code.

So we could have these options:
1) provide a sablejit patch for SableVM
2) add SableJIT support to sablevm/staging, all code is #ifdef SABLEJIT* =
though
   some clutter files, especially prepared_code.c.
3) use sablejit/staging
   created subdir sablevm/ with patched SableVM
   created subdir sablejit/ with Java code
   In that case we have 2 staging version of SableVM, 1 with jit support,
   the other without.

Any suggestion/comments?


> * The next thing seems to be this long-promised and awaited closer
> integration with GNU Classpath. It's in the works, I'll send more info
> as soon as the idea of implementing it in realistic way stabilizes.
>=20

yes.


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

[Sablevm-developer] On the 1.1.1 release and further

[Grzegorz B. P. <ga...@de...>]

Hi all,

I wanted to ask you for opinions and suggestions about how and when
should SableVM 1.1.1 release happend. Below you'll find what I think
about it, given our last experiences with 1.1.0 and current state of the
affairs. I also touch some further issues. Even if you (accidentally)
agree with the below, I'd love to hear it.

SableVM 1.1.1 release objectives:
* Fixes of grave bugs since 1.1.0 (like waitfor())
* Enchancements since 1.1.0
  - new classpath 0.08 (soon to be released)
  - David's fillings in the JNI interface
  - Thread.interrupt() and (if I make it on time) EnsureLocalCapacity()
* Get more attention as our conficence in 1.1.1 is bigger (announces
  on sablevm-announce, freshmeat, etc. - should we call it "1.2 beta?")

SableVM 1.1.1 release path (based on what worked for us before):
1. Importing new Classpath release
2. Merging new Classpath into staging
3. Testing the codebase
4. Making and announcing the release

Last time 1) was done by Etienne, 2) by David, 3) by Chris,  4) by me.
I think that besides some side issues and bad timing caused by things
beyond our influence, it worked pretty well, so it'd be great, if this
time also everyone could put his share in the process.  (I'd be
particularly interested in helping with 2), but only if I have
interrupt() and EnsureLocalCapacity() done by that time)


Another thing is SableJIT release. It's up to David when it happens,
but I think we shouldn't wait too long with releasing this code as a
_development_ release. We can even do it along 1.1.1, why not? I think
that this way David (and we all) could get some bugreports from the
users or/and gain confidence that SableJIT is actually usable in
the real, wild world ;-) And for some people word "JIT" is magical...


Beyond SableVM 1.1.1:
* I think 1.1.1 shouldn't bring us (m)any bad surprises. The less of
these, the sooner we could release 1.2.0. It really is very important
to make a new _stable_ release. Most of people is not keen on using
releases marked "development", even if ours are rock-stable compared
to what other FLOSS projects release with such sticker.
* The next thing seems to be this long-promised and awaited closer
integration with GNU Classpath. It's in the works, I'll send more info
as soon as the idea of implementing it in realistic way stabilizes.


You might have noticed that I am trying to focus mostly on the user-POV,
general usability things. And this is on a purpose. SableVM is just too
good to get a sticker of "Research VM" which is perceived as not meant
for real world usage. We all know that's not true and I am sure that
seriousness of our (not necessarily directly user-visible, but in the
end important for enduser) work in SableVM Project becomes much more
apparent when we clearly show that.

We're doing that already, we just need to keep it going.

				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

Re: [Sablevm-developer] using a Soot-transformed classpath

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

>W liście z sob, 06-03-2004, godz. 21:41, Etienne Gagnon pisze: 
>  
>
>>On Fri, Mar 05, 2004 at 11:45:07PM -0500, Chris Pickett wrote:
>>    
>>
>>>>I want to make SableVM use Soot-transformed versions of the non-native 
>>>>portion of Classpath.  I have the output from Soot in the application 
>>>>directory where I try to run SableVM, but the classes aren't getting 
>>>>loaded even with '-c .' specified as an option.
>>>>        
>>>>
>>How about compiling a version of SableVM with
>>--enable-debugging-features and then launching sablevm like this:
>>
>> sablevm -v --property sablevm.verbose.methods=true ...
>>
>>This should show you the complete sequence of called methods.  I guess
>>we should really document these boot-time properties somewhere.  Any
>>volunteer?
>>    
>>
>
>Ehrm...! does _anybody_ read manual pages?! ;-)
>
>$ man sablevm
>
>(though suggestions/improvements are welcomed)
>  
>

not sure if you last changed it very recently, but for me, only 
sablevm.verbose.methods and sablevm.verbose.instructions are there.  
perhaps the best solution is to generate that portion of the file from 
vm_args.(m4?).c -- that way, it always stays up to date.

cheers,
chris

p.s.  java.lang.Object superclass problem is solved for me, but soot and 
d-java are still broken, for those who aren't on the soot list.

Re: [Sablevm-developer] Thread.interrupted() SOLVED (again? ;-)

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

>Hi again,
>
>I think I finally did it, w/o any compromises on specs conformance.
>It should work fully according to Java specs about interrupt() and
>OpenGroup specs about pthread_cond_* usage and features. Though it's
>unfortunatelly much more complicated (I guess I finally found out why
>the other implementations weren't that small and simple as mine first
>;-)
>
>Anyway, the changes are in my sandbox, see:
>svn diff -r 1700:HEAD
>svn://svn.sablevm.org/developers/gadek/sandbox/svn-interrupt
>
>I want to sleep it over, but if till the evening I don't find anything
>bad in this implementation and don't get any improvement suggestions,
>I am putting that into staging.
>  
>

Why don't you try some Thread.interrupted() benchmarks and perhaps also 
some small programs that you write to call it intensively?

Re: [Sablevm-developer] Errno usage considered harmful?!

[Etienne G. <gag...@uq...>]

Hi Greg,

Grzegorz B. Prokopski wrote:
> 1. If I add:
>   #include <errno.h>
>   extern int errno;
> I get such warning:
>   java_lang_ProcessImpl.c:24: warning: function declaration isn't a
> prototype

You should NEVER declare errno.  #include <errno.h> declares it
appropriately.  (It can be a macro, of many things, specially when you
compile with multi-threading support).

> 2. In interrupt() implementation I use a pointer to pthread_cond_t:
>   volatile pthread_cond_t *sleeping_on_cond;
> I also keep getting this warning:
>   java_lang_VMThread.c:342: warning: passing arg 1 of
>   `pthread_cond_broadcast' discards qualifiers from pointer target type
> which is such code:
>   pthread_cond_broadcast (env_other->thread.sleeping_on_cond);

Why aren't you using SableVM's wrapper for broadcasting?  I think that
we should discuss your code in my office; it would be quicker than long
emails...

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Errno usage considered harmful?!

[Clark V. <cl...@CS...>]

I have some guesses, below.

-- 
ttfn,
clark
cl...@cs...


On Wed, 10 Mar 2004, Grzegorz B. Prokopski wrote:

> Hi all,
> 
> I have strange problems with compiler warnings:
> 
> 1. If I add:
>   #include <errno.h>
>   extern int errno;
> I get such warning:
>   java_lang_ProcessImpl.c:24: warning: function declaration isn't a
> prototype

It would help to know which line is line 24, but here's something that may
be worth checking:  Although the extern declaration should be fine, errno
may be declared as a macro rather than a simple variable --- particularly
with multithreaded code, where errno's exist for each separate thread.  
Try just using the include and removing the "extern int errno;" statement.

> 2. In interrupt() implementation I use a pointer to pthread_cond_t:
>   volatile pthread_cond_t *sleeping_on_cond;
> I also keep getting this warning:
>   java_lang_VMThread.c:342: warning: passing arg 1 of
>   `pthread_cond_broadcast' discards qualifiers from pointer target type
> which is such code:
>   pthread_cond_broadcast (env_other->thread.sleeping_on_cond);

The prototype for cond_broadcast doesn't expect a volatile type for the
argument, so that qualifier is being discarded when you call the function.
An explicit cast may eliminate the warning, but the problem is that the
cond_broadcast code was not compiled assuming volatile input arguments.  
If that's a problem then you'll need to re-examine why you need volatile
in sleeping_on_cond.

> Not sure how to deal with these two. Suggestions are very welcomed. [*]
> 
> Cheers,
> 
> 				Grzegorz B. Prokopski
> 
> [*] Like a good RTFM, for ex.
> 
> 

Re: [Sablevm-developer] Thread.interrupted() SOLVED (again? ;-)

[Grzegorz B. P. <ga...@de...>]

Hi again,

I think I finally did it, w/o any compromises on specs conformance.
It should work fully according to Java specs about interrupt() and
OpenGroup specs about pthread_cond_* usage and features. Though it's
unfortunatelly much more complicated (I guess I finally found out why
the other implementations weren't that small and simple as mine first
;-)

Anyway, the changes are in my sandbox, see:
svn diff -r 1700:HEAD
svn://svn.sablevm.org/developers/gadek/sandbox/svn-interrupt

I want to sleep it over, but if till the evening I don't find anything
bad in this implementation and don't get any improvement suggestions,
I am putting that into staging.

Cheers,

					GBP
-- 
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

[Sablevm-developer] Errno usage considered harmful?!

[Grzegorz B. P. <ga...@de...>]

Hi all,

I have strange problems with compiler warnings:

1. If I add:
  #include <errno.h>
  extern int errno;
I get such warning:
  java_lang_ProcessImpl.c:24: warning: function declaration isn't a
prototype

2. In interrupt() implementation I use a pointer to pthread_cond_t:
  volatile pthread_cond_t *sleeping_on_cond;
I also keep getting this warning:
  java_lang_VMThread.c:342: warning: passing arg 1 of
  `pthread_cond_broadcast' discards qualifiers from pointer target type
which is such code:
  pthread_cond_broadcast (env_other->thread.sleeping_on_cond);

Not sure how to deal with these two. Suggestions are very welcomed. [*]

Cheers,

				Grzegorz B. Prokopski

[*] Like a good RTFM, for ex.

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

[Sablevm-developer] Bug#231872: marked as done (/usr/bin/jikes-sablevm: javac reports: "Cannot find/read SableVM classes. Please report")

[<ow...@bu...>]

Your message dated Tue, 09 Mar 2004 18:25:09 -0500
with message-id <107...@ga...>
and subject line fixed long ago: /usr/bin/jikes-sablevm not finding classes
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--------------------------------------
Received: (at submit) by bugs.debian.org; 9 Feb 2004 11:25:27 +0000
>From an...@ma... Mon Feb 09 03:25:27 2004
Return-path: <an...@ma...>
Received: from smtp-101-monday.noc.nerim.net (mallaury.noc.nerim.net) [62.4.17.101] 
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1Aq9Xb-0003kF-00; Mon, 09 Feb 2004 03:25:27 -0800
Received: from scrat (riedler.net1.nerim.net [213.41.137.10])
	by mallaury.noc.nerim.net (Postfix) with ESMTP
	id 57D4C62E1D; Mon,  9 Feb 2004 12:25:25 +0100 (CET)
Received: from andrew by scrat with local (Exim 4.30)
	id 1Aq9XY-0003hu-WC; Mon, 09 Feb 2004 12:25:24 +0100
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Andrew Maier <an...@ma...>
To: Debian Bug Tracking System <su...@bu...>
Subject: /usr/bin/jikes-sablevm: javac reports: "Cannot find/read SableVM classes.
 Please report"
X-Mailer: reportbug 2.39
Date: Mon, 09 Feb 2004 12:25:24 +0100
Message-Id: <E1Aq9XY-0003hu-WC@scrat>
Sender: Andrew Maier <an...@ma...>
Delivered-To: su...@bu...
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_02_01 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no 
	version=2.60-bugs.debian.org_2004_02_01
X-Spam-Level: 

Package: jikes-sablevm
Version: 1.0.9+svn20040120-2
Severity: important
File: /usr/bin/jikes-sablevm
Tags: patch


The javac wrapper does not load the correct classpath for jikes:

Looking into the wrapper script

  jikes -bootclasspath `cat /usr/share/sablevm/classlib.pth` "$@"

it tries to cat the file  /usr/share/sablevm/classlib.pth, which does
not exit.

replaceing the line with  
  
	jikes -bootclasspath  /usr/share/sablevm/classpath

solves this.

Best regards,

	Andrew



-- System Information:
Debian Release: testing/unstable
Architecture: alpha
Kernel: Linux scrat 2.4.24.am #1 Fri Jan 9 11:05:51 CET 2004 alpha
Locale: LANG=en_IE.ISO-8859-15@euro, LC_CTYPE=en_IE.ISO-8859-15@euro

Versions of packages jikes-sablevm depends on:
ii  java-common          0.22                Base of all Java packages
ii  jikes                1:1.18-7            Fast Java compiler adhering to lan
ii  libsablevm-classlib1 1.0.9+svn20040115-1 GNU Classpath modified to work wit

-- no debconf information


---------------------------------------
Received: (at 231872-done) by bugs.debian.org; 9 Mar 2004 23:44:19 +0000
>From ga...@de... Tue Mar 09 15:44:18 2004
Return-path: <ga...@de...>
Received: from anis.telecom.uqam.ca [132.208.250.6] 
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1B0qtW-0002gf-00; Tue, 09 Mar 2004 15:44:18 -0800
Received: from anis4.telecom.uqam.ca (anis4.telecom.uqam.ca [132.208.250.236])
	by sortant.uqam.ca (8.12.10/8.12.1) with SMTP id i29NUEKt004655;
	Tue, 9 Mar 2004 18:30:14 -0500 (EST)
Received: from antivirus.uqam.ca ([132.208.250.6])
 by anis4.telecom.uqam.ca (SAVSMTP 3.1.1.32) with SMTP id M2004030918311909246
 ; Tue, 09 Mar 2004 18:31:19 -0500
Received: from 57.28.internet.uqam.ca (57.28.internet.uqam.ca [132.208.28.57])
	by intrant.uqam.ca (8.12.10/8.12.2/uqam-filtres) with ESMTP id i29NPBam005850;
	Tue, 9 Mar 2004 18:25:13 -0500 (EST)
X-Spam-Filter: Filtre-Uqam re:  ab...@uq...
Subject: fixed long ago: /usr/bin/jikes-sablevm not finding classes
From: "Grzegorz B. Prokopski" <ga...@de...>
To: 231...@bu...
Cc: an...@ma...
Content-Type: text/plain
Organization: Debian GNU/Linux http://www.debian.org
Message-Id: <107...@ga...>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Tue, 09 Mar 2004 18:25:09 -0500
Content-Transfer-Encoding: 7bit
Delivered-To: 231...@bu...
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_08 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no 
	version=2.60-bugs.debian.org_2004_03_08
X-Spam-Level: 

fixed in 1.1.0 upload

				GBP

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

Re: [Sablevm-developer] Thread.interrupted() TROUBLES

[Grzegorz B. P. <ga...@de...>]

Hi again,

Today I discussed the implementation with Etienne, and corrected it a
bit. But I was terribly surprised when later it completly didn't work.
What's more interesting - the code that worked yesterday - now also
doesn't work! (test case java class attached)

What has changed is that apparently sending SIGUSR1 to a thread
blocked in pthread_cond_timedwait does NOT wake it up (anymore?)!
Manual page still says this:

The pthread_cond_timedwait function returns the following error codes on
error:
   ETIMEDOUT - the condition variable was not signaled until the timeout
               specified by |abstime|
   EINTR     - pthread_cond_timedwait was interrupted by a signal

So I thought there's some new bug after upgrades I did yesterday... but
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_cond_wait.html
says:

"If a signal is delivered to a thread waiting for a condition variable,
 upon return from the signal handler the thread resumes waiting for the
 condition variable as if it was not interrupted, or it shall return
 zero due to spurious wakeup."

and later:

"These functions shall not return an error code of [EINTR]."

So it looks like for each thread we would need to store information
where it currently is waiting (if anywhere) and if needed - signal such
thread to unblock (or rather all of the waiting threads). These two look
promising, though I think it's more logical to use ..._broadcast().

int pthread_cond_broadcast(pthread_cond_t *cond);
int pthread_cond_signal(pthread_cond_t *cond);

I'll try to implement that tomorrow but if anybody has better idea,
or some advices, I'll be glad to hear.

eh, TANSTAAFL...

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

Re: [Sablevm-developer] using a Soot-transformed classpath

[Grzegorz B. P. <ga...@de...>]

W li=B6cie z pon, 08-03-2004, godz. 15:07, Chris Pickett pisze:=20
> Clark VERBRUGGE wrote:
> >>is this a soot bug?  generating code for java.lang.Object that declar=
es=20
> >>java.lang.Object as a superclass?  or is there something particular t=
o=20
> >>what i'm doing that forces java.lang.Object as a superclass (i don't =
see=20
> >>it ...)
> >>
> >>i checked the jasmin disassembly of the transformed java.lang.Object=20
> >>classfile and it does indeed declare '.super java/lang/Object'
> >=20
> >=20
> > The super_class field of the classfile for java.lang.Object should be=
 0
> > (ie invalid constant-pool ref), so that sounds like a soot bug.
>=20
>=20
> Eric Bodden on the Soot list said it might be because two copies of=20
> java.lang.Object are in my classpath.  I tried the most minimal=20
> classpath I could find, and still had this problem.

> Can somebody else with sablevm-classpath installed verify this?  It=20
> takes less than 5 minutes.  I'm going a bit crazy with all these=20
> classpath issues.

I've just checked that with Kaffe's java compiler (KCJ) and Sun's
javac and they all dissasemble to this:

.source Object.java
.class  public java/lang/Object
; ACC_SUPER bit is set
.super  java/lang/Object

I imagine that by default, if there's no superclass, it's assumed to
be java/lang/Object, no matter what. I guess it might need a workaround
in Soot then.

HTH

					GBP

--=20
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

[Sablevm-developer] Bug#176628: marked as done (java.awt.* classess don't work as expected for)

[<ow...@bu...>]

Your message dated Mon, 08 Mar 2004 13:51:56 -0500
with message-id <107...@ga...>
and subject line AWT now works w/ SableVM
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--------------------------------------
Received: (at submit) by bugs.debian.org; 14 Jan 2003 06:37:33 +0000
>From gi...@po... Tue Jan 14 00:37:32 2003
Return-path: <gi...@po...>
Received: from dhcp64-134-66-129.four.sjc.wayport.net (mail.fire-swamp.org) [64.134.66.129] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 18YKhX-0002so-00; Tue, 14 Jan 2003 00:37:31 -0600
Received: from srz by mail.fire-swamp.org with local (Exim 3.36 #1 (Debian))
	for su...@bu...
	id 18Y8MQ-0000Ba-00; Mon, 13 Jan 2003 09:26:54 -0800
From: Stephen Zander <srz@localhost>
To: Debian Bug Tracking System <su...@bu...> 
Subject: sablevm: package incorrctly provides java1-runtime 
X-Debbugs-CC: Stephen Zander <srz@localhost>
Message-Id: <E18...@ma...>
Sender: Stephen Zander <gi...@po...>
Date: Mon, 13 Jan 2003 09:26:54 -0800
Delivered-To: su...@bu...
X-Spam-Status: No, hits=4.8 required=5.0
	tests=DATE_IN_PAST_12_24,FROM_MALFORMED,SPAM_PHRASE_00_01
	version=2.41
X-Spam-Level: ****

Package: sablevm
Version: 1.0.5-1
Severity: important

According to the Java policy, packages that provide java1-runtime must
support the the complete java runtime environment.  As sablevm fails
to provide working java.awt.* classes, the provides on this package is
incorrect.  Please remove it until such time as sablevm has working
support for java.awt.*.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux pooh 2.4.19 #2 Wed Sep 11 21:14:15 PDT 2002 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages sablevm depends on:
ii  java-common                0.16          Base of all Java packages
ii  libc6                      2.3.1-9       GNU C Library: Shared libraries an
ii  libffi2                    1:3.2.2-0pre5 Foreign Function Interface library
ii  libltdl3                   1.4.3-5       A system independent dlopen wrappe
ii  libpopt0                   1.6.4-2       lib for parsing cmdline parameters
ii  libsablevm-classlib1-java  1.0.5-1       GNU Classlib modified to work with
ii  libsablevm-native1         1.0.5-1       Architecture dependent SableVM JVM
ii  libsablevm1                1.0.5-1       Free implementation of JVM secon e

-- no debconf information


---------------------------------------
Received: (at 176628-done) by bugs.debian.org; 8 Mar 2004 21:22:45 +0000
>From ga...@de... Mon Mar 08 13:22:45 2004
Return-path: <ga...@de...>
Received: from anis.telecom.uqam.ca [132.208.250.6] 
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1B0SCz-0003DF-00; Mon, 08 Mar 2004 13:22:45 -0800
Received: from anis4.telecom.uqam.ca (anis4.telecom.uqam.ca [132.208.250.236])
	by sortant.uqam.ca (8.12.10/8.12.1) with SMTP id i28JQ6M1009576;
	Mon, 8 Mar 2004 14:37:12 -0500 (EST)
Received: from antivirus.uqam.ca ([132.208.250.6])
 by anis4.telecom.uqam.ca (SAVSMTP 3.1.1.32) with SMTP id M2004030814344329996
 ; Mon, 08 Mar 2004 14:34:43 -0500
Received: from 57.28.internet.uqam.ca (57.28.internet.uqam.ca [132.208.28.57])
	by intrant.uqam.ca (8.12.10/8.12.2/uqam-filtres) with ESMTP id i28IpwuQ000757;
	Mon, 8 Mar 2004 13:51:58 -0500 (EST)
X-Spam-Filter: Filtre-Uqam re:  ab...@uq...
Subject: Re: AWT now works w/ SableVM
From: "Grzegorz B. Prokopski" <ga...@de...>
To: Stephen Zander <gi...@de...>
Cc: 176...@bu..., Matthias Klose <do...@cs...>,
        Ben Burton <ba...@de...>
In-Reply-To: <87s...@fi...>
References: <107...@ga...>
	 <87s...@fi...>
Content-Type: text/plain; charset=ISO-8859-2
Organization: Debian GNU/Linux http://www.debian.org
Message-Id: <107...@ga...>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Mon, 08 Mar 2004 13:51:56 -0500
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by anis.telecom.uqam.ca id i28JQ6M1009576
Delivered-To: 176...@bu...
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_08 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no 
	version=2.60-bugs.debian.org_2004_03_08
X-Spam-Level: 

Hi!

Things have changed since these few days. Now SableVM (in Debian only,
ATM) implements interrupt(), isInterrupted(),... see the result here:

http://gadek.debian.net/SableVM-SymbolTest-Working.png

No hacks used, no more error messages.

Once SableVM 1.1.1 is out (with cleaned-up version of the implementation
of the above methods and a few other fixes), hopefully soon after
Classpath 0.08 release I'll announce that and ask to re-try SableVM on
even more apps. Your help then will be invaluable.

At 1.1.1 point bugreports like this one will be very, very welcomed, as
we'll be heading towards our first stable release since a year: 1.2.0.
So we'll really want to make sure things _do work_ and to know which
don't and why.

Thank you all very much for your help and input

				Grzegorz B. Prokopski

W li=B6cie z pon, 08-03-2004, godz. 00:33, Stephen Zander pisze:=20
> >>>>> "Grzegorz" =3D=3D Grzegorz B Prokopski <ga...@de...> writes:
>     Grzegorz> In SableVM the controls that showed up basically worked,
>     Grzegorz> though I was getting tons of such messages: *** Couldn't
>     Grzegorz> bind native method Java_java_lang_VMThread_isInterrupted
>     Grzegorz> *** *** or Java_java_lang_VMThread_isInterrupted__ ***
>     Grzegorz> Exception during event dispatch:
>     Grzegorz> java.lang.UnsatisfiedLinkError at
>     Grzegorz> java.lang.VMThread.isInterrupted (VMThread.java) at
>     Grzegorz> java.lang.Thread.isInterrupted (Thread.java:566) at
>     Grzegorz> java.awt.EventDispatchThread.run
>     Grzegorz> (EventDispatchThread.java:65) at
>     Grzegorz> java.lang.VMThread.callRun (VMThread.java:116) at
>     Grzegorz> java.lang.Thread.callRun (Thread.java:343) at
>     Grzegorz> java.lang.VirtualMachine.runThread
>     Grzegorz> (VirtualMachine.java:117)
>=20
> Half-working is still half-broken.  I'm happy to leave this as a
> normal bug however.



--=20
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

Re: [Sablevm-developer] using a Soot-transformed classpath

[Chris P. <chr...@ma...>]

Clark VERBRUGGE wrote:
>>is this a soot bug?  generating code for java.lang.Object that declares 
>>java.lang.Object as a superclass?  or is there something particular to 
>>what i'm doing that forces java.lang.Object as a superclass (i don't see 
>>it ...)
>>
>>i checked the jasmin disassembly of the transformed java.lang.Object 
>>classfile and it does indeed declare '.super java/lang/Object'
> 
> 
> The super_class field of the classfile for java.lang.Object should be 0
> (ie invalid constant-pool ref), so that sounds like a soot bug.


Eric Bodden on the Soot list said it might be because two copies of 
java.lang.Object are in my classpath.  I tried the most minimal 
classpath I could find, and still had this problem.

What's weird is that with D-Java from

http://www.netsw.org/softeng/lang/java/bytecode/disassembler/djava/

I get:

$ cd ~/lib/sablevm/classpath
$ D-Java java/lang/Object.class -o jasmin

;>> java/lang/Object.class <<
;
; Output created by D-Java (Mar  8 2004)
; mailto:ums...@cc...
; Copyright (c) 1996-1997 Shawn Silverman
;

;Classfile version:
;    Major: 45
;    Minor: 3

.source Object.java
.class  public java/lang/Object
; ACC_SUPER bit is set
.super  java/lang/Object
^^^^^^^^^^^^^^^^^^^^^^^^

[...]

on a newly-installed classpath, which really doesn't make sense to me. 
Furthermore, when I step through this with gdb and sablevm, it doesn't 
think java.lang.Object has a superclass.  I installed D-Java to get 
straight jasmin output and try to pin down this problem -- Soot does 
some rearranging of instructions before spitting out Jasmin.

Can somebody else with sablevm-classpath installed verify this?  It 
takes less than 5 minutes.  I'm going a bit crazy with all these 
classpath issues.

Cheers, and thanks,
Chris

Re: [Sablevm-developer] using a Soot-transformed classpath

[Clark V. <cl...@CS...>]

> is this a soot bug?  generating code for java.lang.Object that declares 
> java.lang.Object as a superclass?  or is there something particular to 
> what i'm doing that forces java.lang.Object as a superclass (i don't see 
> it ...)
> 
> i checked the jasmin disassembly of the transformed java.lang.Object 
> classfile and it does indeed declare '.super java/lang/Object'

The super_class field of the classfile for java.lang.Object should be 0
(ie invalid constant-pool ref), so that sounds like a soot bug.

-- 
ttfn,
clark
cl...@cs...


On Sun, 7 Mar 2004, Chris Pickett wrote:

> Etienne Gagnon wrote:
> > On Fri, Mar 05, 2004 at 11:45:07PM -0500, Chris Pickett wrote:
> > 
> >>>I want to make SableVM use Soot-transformed versions of the non-native 
> >>>portion of Classpath.  I have the output from Soot in the application 
> >>>directory where I try to run SableVM, but the classes aren't getting 
> >>>loaded even with '-c .' specified as an option.
> > 
> > 
> > How about compiling a version of SableVM with
> > --enable-debugging-features and then launching sablevm like this:
> > 
> >  sablevm -v --property sablevm.verbose.methods=true ...
> 
> i use vm->verbose_methods and vm->verbose_instructions all the time :(
> 
> i should have reported more details at first; i was just wondering if 
> somebody knew off the top of their head why it fails.
> 
> anyway, to make it quick:  i followed it through with gdb and it dies 
> loading java.lang.Object because apparently java.lang.Object has a 
> superclass (relevant code follows).
> 
> if i just replace java.lang.Object with the orignal, then it dies 
> whenever it tries to load Spmt.class (which can be deferred by copying 
> over more non-transformed classes).
> 
> i found that if i keep the original Object.class, VMClass.class, and 
> Class.class files, and also put Spmt.class in the root of classpath, 
> then it works fine.  anything less is insufficient.
> 
> however, i would really like to have my special instructions inserted 
> around every method call -- i want to gather statistics on the number of 
> calls we can successfully predict when the whole of classpath is 
> transformed.
> 
> is this a soot bug?  generating code for java.lang.Object that declares 
> java.lang.Object as a superclass?  or is there something particular to 
> what i'm doing that forces java.lang.Object as a superclass (i don't see 
> it ...)
> 
> i checked the jasmin disassembly of the transformed java.lang.Object 
> classfile and it does indeed declare '.super java/lang/Object'
> 
> cheers,
> chris
> 
> ==========================================
> 
> static jint
> _svmf_bootcl_resolve_super_class (_svmt_JNIEnv *env, _svmt_class_info 
> *class)
> {
>    _svmt_JavaVM *vm = env->vm;
>    _svmt_CONSTANT_Class_info **cp_super_class = class->super_class;
> 
>    assert (class->class_loader_info->class_loader == NULL);
> 
>    /* no super class -> we're done */
>    if (CANNOT_DREF (cp_super_class))
>      {
>        /* this must be "java/lang/Object" */
>        /* and it must be a public non-abstract non-final class */
>        if (strcmp (class->name, "java/lang/Object") != 0 ||
>            class->class_loader_info->class_loader != NULL ||
>            (!_svmf_is_set_flag (class->access_flags, SVM_ACC_PUBLIC)) ||
>            _svmf_is_set_flag (class->access_flags, SVM_ACC_FINAL) ||
>            _svmf_is_set_flag (class->access_flags, SVM_ACC_INTERFACE) ||
>            _svmf_is_set_flag (class->access_flags, SVM_ACC_ABSTRACT))
>          {
>            _svmf_error_VerifyError (env);
>            return JNI_ERR;
>          }
> 
>        return JNI_OK;
>      }
> 
>    if (DREF (cp_super_class, tag) != SVM_CONSTANT_Class ||
>        CANNOT_DREF (DREF (cp_super_class, name)) ||
>        DREF (DREF (cp_super_class, name), tag) != SVM_CONSTANT_Utf8 ||
>        DREF (DREF (cp_super_class, name), value)[0] == '[')
>      {
>        _svmf_error_ClassFormatError (env);
>        return JNI_ERR;
>      }
> 
>    {
>      _svmt_type_node type = { NULL, NULL, NULL, NULL, NULL };
> 
>      type.name = DREF (DREF (cp_super_class, name), value);
> 
>      if (_svmm_tree_find_type
>          (vm->class_loading.boot_loader.partially_derived_type_tree,
>           &type) != NULL)
>        {
> =>      _svmf_error_ClassCircularityError (env);
>          return JNI_ERR;
>        }
>    }
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer
> 
> 

Re: [Sablevm-developer] using a Soot-transformed classpath

[Chris P. <chr...@ma...>]

Etienne Gagnon wrote:
> On Fri, Mar 05, 2004 at 11:45:07PM -0500, Chris Pickett wrote:
> 
>>>I want to make SableVM use Soot-transformed versions of the non-native 
>>>portion of Classpath.  I have the output from Soot in the application 
>>>directory where I try to run SableVM, but the classes aren't getting 
>>>loaded even with '-c .' specified as an option.
> 
> 
> How about compiling a version of SableVM with
> --enable-debugging-features and then launching sablevm like this:
> 
>  sablevm -v --property sablevm.verbose.methods=true ...

i use vm->verbose_methods and vm->verbose_instructions all the time :(

i should have reported more details at first; i was just wondering if 
somebody knew off the top of their head why it fails.

anyway, to make it quick:  i followed it through with gdb and it dies 
loading java.lang.Object because apparently java.lang.Object has a 
superclass (relevant code follows).

if i just replace java.lang.Object with the orignal, then it dies 
whenever it tries to load Spmt.class (which can be deferred by copying 
over more non-transformed classes).

i found that if i keep the original Object.class, VMClass.class, and 
Class.class files, and also put Spmt.class in the root of classpath, 
then it works fine.  anything less is insufficient.

however, i would really like to have my special instructions inserted 
around every method call -- i want to gather statistics on the number of 
calls we can successfully predict when the whole of classpath is 
transformed.

is this a soot bug?  generating code for java.lang.Object that declares 
java.lang.Object as a superclass?  or is there something particular to 
what i'm doing that forces java.lang.Object as a superclass (i don't see 
it ...)

i checked the jasmin disassembly of the transformed java.lang.Object 
classfile and it does indeed declare '.super java/lang/Object'

cheers,
chris

==========================================

static jint
_svmf_bootcl_resolve_super_class (_svmt_JNIEnv *env, _svmt_class_info 
*class)
{
   _svmt_JavaVM *vm = env->vm;
   _svmt_CONSTANT_Class_info **cp_super_class = class->super_class;

   assert (class->class_loader_info->class_loader == NULL);

   /* no super class -> we're done */
   if (CANNOT_DREF (cp_super_class))
     {
       /* this must be "java/lang/Object" */
       /* and it must be a public non-abstract non-final class */
       if (strcmp (class->name, "java/lang/Object") != 0 ||
           class->class_loader_info->class_loader != NULL ||
           (!_svmf_is_set_flag (class->access_flags, SVM_ACC_PUBLIC)) ||
           _svmf_is_set_flag (class->access_flags, SVM_ACC_FINAL) ||
           _svmf_is_set_flag (class->access_flags, SVM_ACC_INTERFACE) ||
           _svmf_is_set_flag (class->access_flags, SVM_ACC_ABSTRACT))
         {
           _svmf_error_VerifyError (env);
           return JNI_ERR;
         }

       return JNI_OK;
     }

   if (DREF (cp_super_class, tag) != SVM_CONSTANT_Class ||
       CANNOT_DREF (DREF (cp_super_class, name)) ||
       DREF (DREF (cp_super_class, name), tag) != SVM_CONSTANT_Utf8 ||
       DREF (DREF (cp_super_class, name), value)[0] == '[')
     {
       _svmf_error_ClassFormatError (env);
       return JNI_ERR;
     }

   {
     _svmt_type_node type = { NULL, NULL, NULL, NULL, NULL };

     type.name = DREF (DREF (cp_super_class, name), value);

     if (_svmm_tree_find_type
         (vm->class_loading.boot_loader.partially_derived_type_tree,
          &type) != NULL)
       {
=>      _svmf_error_ClassCircularityError (env);
         return JNI_ERR;
       }
   }

Re: [Sablevm-developer] Thread.interrupted() solution

[Grzegorz B. P. <ga...@de...>]

Hi again,

sometimes it's good to put things in writing. I think I should have it
solved now. This is how it's supposed to work:

I have two flags
 env->thread.interrupted - the same meaning as Thread.interrupted()
 env->thread.interrupted_signalled
both initially JNI_FALSE

interrupt handler simply sets interrupted_signalled = JNI_TRUE;

before each C function that can return EINTR which I want to possibly
turn into InterruptedException I set interrupted_signalled to JNI_FALSE;

If I get EINTR and interrupted_signalled changed state to JNI_TRUE
I set interrupted to JNI_TRUE and throw InterrupedException

Thread.interrupted() returns interrupted flag and sets it to JNI_FALSE
Thread.isInterrupted() returns interrupted flag

No locking and atomicity anywhere and so far I can't see any reason
for it.

ATM I think it pretty much should solve all of the problems I outlined
in my other mail, though I might be wrong, as the other implementations
I saw were much more complicated.

My current version of changes is available using command:

svn diff -r 1700:HEAD
svn://svn.sablevm.org/developers/gadek/sandbox/svn-interrupt

(this branch also contains a cople of other fixes but not many)

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

Re: [Sablevm-developer] using a Soot-transformed classpath

[Grzegorz B. P. <ga...@de...>]

W li=B6cie z sob, 06-03-2004, godz. 21:41, Etienne Gagnon pisze:=20
> On Fri, Mar 05, 2004 at 11:45:07PM -0500, Chris Pickett wrote:
> > >I want to make SableVM use Soot-transformed versions of the non-nati=
ve=20
> > >portion of Classpath.  I have the output from Soot in the applicatio=
n=20
> > >directory where I try to run SableVM, but the classes aren't getting=
=20
> > >loaded even with '-c .' specified as an option.
>=20
> How about compiling a version of SableVM with
> --enable-debugging-features and then launching sablevm like this:
>=20
>  sablevm -v --property sablevm.verbose.methods=3Dtrue ...
>=20
> This should show you the complete sequence of called methods.  I guess
> we should really document these boot-time properties somewhere.  Any
> volunteer?

Ehrm...! does _anybody_ read manual pages?! ;-)

$ man sablevm

(though suggestions/improvements are welcomed)

			GBP

PS: Assuming you have SableVM installed in some standard place so that
man command knew about sablevm.1 manual page... 'man ./doc/sablevm.1'
in SableVM sources should also work AFAIR.

--=20
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

Re: [Sablevm-developer] using a Soot-transformed classpath

[Etienne G. <gag...@uq...>]

On Fri, Mar 05, 2004 at 11:45:07PM -0500, Chris Pickett wrote:
> >I want to make SableVM use Soot-transformed versions of the non-native 
> >portion of Classpath.  I have the output from Soot in the application 
> >directory where I try to run SableVM, but the classes aren't getting 
> >loaded even with '-c .' specified as an option.

How about compiling a version of SableVM with
--enable-debugging-features and then launching sablevm like this:

 sablevm -v --property sablevm.verbose.methods=true ...

This should show you the complete sequence of called methods.  I guess
we should really document these boot-time properties somewhere.  Any
volunteer?

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] gcc bug or not?

[Etienne G. <gag...@uq...>]

On Sat, Mar 06, 2004 at 04:03:57PM -0500, David B?langer wrote:
> So either the evaluation order of the arguments in C is undefined (gcc
> gives no warning for that code) 

C is not Java: argument evaluation order is undefined in C.  Portable C code
should NOT assume any order.

> Any suggestion/comments from C and gcc experts?

I think I will put the C standard manual as a required reading for all
my graduate students in the future. ;-)

Etienne
-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] Thread.interrupted() - mess? (screenshot!)

[Grzegorz B. P. <ga...@de...>]

Hi all, it'll be a longer email...

I have a working implementation of interrupted(). I must say it's not
the best documented part of Java platform, so between the moment
I started a few days ago (and in fact coded it) and now, I had some
discussions (notably with Tom Tromey and Mark Wielaard), I also looked
at how JCVM and Kaffe handle these things... And I'll be rewriting it
surely. The question is: how should it work?


Doubts:

* to set a flag in interrupt handler or not

Reasonably simplistic implementation would just check for EINTR, set
the flag in env->thread and throw the exception. But EINTR may also
happen if nobody called interrupt() and AFAIK in many such cases we
should get back to the syscal which was interrupted. On the contrary,
what JCVM does seems a bit dangerous, like getting exclusive VM lock
in signal handler to set flags... Apparently it can be done even
differently - Tom Tromey told me (I haven't looked at the code) GCJ
signal handler for interrupt() does nothing.

So, my conclusion was that best I can do is set
env->thread.interrupted = JNI_TRUE;
env->thread.interrupted_thrown = JNI_FALSE;
in signal handler, w/o any atomicity. I see no reason as we won't get
two same signals at the same time and even if - all they would do would
be to also set the same flags. These flags aren't changed by any other
thread and _the_ thread is stopped while we execute signal handler for
it.

* when a thread is considered to be interrupted?

Is it: when some other thread sends interrupt() or when the thread
actually notices that and throwns the exception? I think rather the
latter, and so should isInterrupted() act (checking both flags).

* what does it mean that a thread notices it's been interrupt()ed?

Even if I have a flag set from interrupt handler and I also check EINTR,
it still may happen, that loooong ago some other thrad called
interrupt() which set the flag but didn't interrupt any syscall, then
after some undefined time I get into completly another method in a
program which happened to call ex. wait() and wait gets EINTR (ex.
pthread_cond_wait() can spuriously wake up! btw. JCVM implementation is
superior here).

So we match the EINTR with set-up-long-ago interrupted flag and we
throw InterruptedExcpetion instead of getting back to *_cond_wait()!

Is that expected behavior?
if not - where should I reset interrupted flag? on the entry to
the wait() function?

* do we need to take into account thread status? Ex. not send the signal
if thread is in SVM_THREAD_STATUS_NOT_RUNNING_JAVA_RESUMING_DISALLOWED?
(if I send the signal the syscall will be interrupted already).

* I wonder how much atomicity we need here. But FWICS it all looks like
"one thread is trying to kick another one but it's not guaranteed to
work" kind of java feature, so I am not sure how much should I worry
about these things. What are the borders of what's acceptable?

Not sure.

				Grzegorz B. Prokopski

PS: Other notes:

* I'll probably send a note when the code for Thread.interrupt() is
put into the SVN (my private branch) for review.

* both JCVM and SableVM seem to share the same bug in wait()
--- sablevm-1.1.0.orig/src/libsablevm/java_lang_VMObject.c
+++ sablevm-1.1.0/src/libsablevm/java_lang_VMObject.c
@@ -259,7 +260,8 @@
            timeout.tv_nsec = now.tv_usec * 1000;

            timeout.tv_sec = timeout.tv_sec + (ms / 1000);
-           timeout.tv_nsec = timeout.tv_nsec + (ms % 1000) + ns;
+           timeout.tv_nsec =
+             timeout.tv_nsec + (ms % 1000) * 1000 * 1000 + ns;

Which usually makes quite big difference if one wants to wait,
say 500ms ;-) (which was previously turned into 500ns)

* See http://gadek.debian.net/SableVM-SymbolTest-Working.png !

which is one of the Sun's standard AWT tests. This _didn't_
really work previously, the symbols weren't drawn. Now it works
just like on Sun's JVM (minus classpath AWT glitches like lack
of text cursor in this edit window where "00" is visible). No
hacks used.

Unfortunatelly debbuggtk still doesn't work fully when it comes
to interrupt()ing another thread. I suspect that it might be
Classpath problem with InterruptedException routing.

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

Re: [Sablevm-developer] gcc bug or not?

[Clark V. <cl...@CS...>]

> So either the evaluation order of the arguments in C is undefined (gcc
> gives no warning for that code) and that the 3rd arg is computed before

Yes, argument evaluation order in C is undefined. :(

--=20
ttfn,
clark
cl...@cs...


On Sat, 6 Mar 2004, David B=E9langer wrote:

>=20
> Hi,
>=20
> I have this code structure in sablevm.c and it was seg faulting
> on OS X/ppc and I noticed recently that it segfaults also on
> Linux/x86 but not Linux/ppc.  This occurs when SableVM is not
> compiled with debugging code.
>=20
> 	  case ARG_JIT_OPTION:
> 	    {
> 	      const char *str =3D NULL;
> 	      int len;
>=20
>               if (...) {
>=20
>                 ...
>=20
>               } else if (strncmp
> 		   (argument, str =3D "intr-count=3D", len =3D strlen (str)) =3D=3D 0=
) {
>=20
>                 ...
>=20
>               } else {
>                 ...
>               }
>=20
> It segfaults in strlen.  The reg containing str on x86 was containing N=
ULL.
>=20
> the 2nd arg or there is a bug in gcc such that gcc cannot compute the
> dependency and reverse them.
>=20
> This occurs only in non-debugging mode.
>=20
> Any suggestion/comments from C and gcc experts?
>=20
> I wi

[Sablevm-developer] gcc bug or not?

[David <db...@cs...>]

Hi,

I have this code structure in sablevm.c and it was seg faulting
on OS X/ppc and I noticed recently that it segfaults also on
Linux/x86 but not Linux/ppc.  This occurs when SableVM is not
compiled with debugging code.

	  case ARG_JIT_OPTION:
	    {
	      const char *str =3D NULL;
	      int len;

              if (...) {

                ...

              } else if (strncmp
		   (argument, str =3D "intr-count=3D", len =3D strlen (str)) =3D=3D 0) =
{

                ...

              } else {
                ...
              }

It segfaults in strlen.  The reg containing str on x86 was containing NUL=
L.

So either the evaluation order of the arguments in C is undefined (gcc
gives no warning for that code) and that the 3rd arg is computed before
the 2nd arg or there is a bug in gcc such that gcc cannot compute the
dependency and reverse them.

This occurs only in non-debugging mode.

Any suggestion/comments from C and gcc experts?

I will work around it by changing the code structure.

My gcc versions are:

x86: 3.3.3 20040110 (prerelease) (Debian)
OS X/ppc: gcc (GCC) 3.1 20020420 (prerelease)
Linux/ppc: gcc-3.3 (GCC) 3.3.2 (Debian)


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