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