Thread: [Sablevm-developer] On the 1.1.1 release and further
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer
|
From: Grzegorz B. P. <ga...@de...> - 2004-03-10 21:53:47
|
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 |
|
From: David <db...@cs...> - 2004-03-11 02:55:55
|
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
|
|
From: Grzegorz B. P. <ga...@de...> - 2004-03-18 23:52:25
|
W li=B6cie z =B6ro, 10-03-2004, godz. 21:37, David B=E9langer pisze:=20 > > 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 thin= k > > 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... >=20 > If you want, it could be added eventually. It is still I vote for yes, the rest is not against. I'd say: it's as _you_ want. > 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 think at this point we should release sth. like sablevm-sablejit-1.1.1 that contains all the needed code.=20 > 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 suppor= t, > the other without. I see... I think that svn://svn.sablevm.org/sablejit/branches/staging should only contain SableJIT code. I think this sablevm-sablejit tarball it doesn't have to come from staging. We might not call it 1.1.1 then, but: sablevm-sablejit-snapshot1.tar.gz (it can be made by re-packing tar.gz created by 'make dist' so that it unpack to sablevm-sablejit-snapshot1 directory) Would you be able to create such tarball with a short instruction how to compile it? I could then announce it along with SableVM 1.1.1 release I want to make 'test' tarballs in a few minutes, then tomorrow evening the 1.1.1 release. Would you be able to prepare tarball + instruction till friday evening? If not, then we'll make a separate release a while later. Cheers, Grzegorz B. Prokopski > > * 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 inf= o > > as soon as the idea of implementing it in realistic way stabilizes. Hmm... still waiting for Mark's response. It's over a week as I mailed him. --=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 |
|
From: Chris P. <chr...@ma...> - 2004-03-11 05:05:27
|
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 |
|
From: Etienne G. <gag...@uq...> - 2004-03-11 15:30:46
|
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/ |
|
From: Etienne G. <gag...@uq...> - 2004-03-11 15:31:33
|
Grzegorz B. Prokopski wrote: > 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... I do not want to see SableJIT code under the /sablevm project tree before the interface to the JIT is cleaned up and made into a minimal one, instead of the "scattered all over the place" current status [unless I am wrong and this has already been fixed]. I really want SableVM's source code to remain as clean and easy to read/modify as possible. I see SableJIT as an "add-on". It's source code should reside mostly (i.e. 99,9%) under the /sablejit project tree. The additional 0.1% should really be some very minimal changes in very few files (and very few places) in SableVM's source code. SableVM's inlined engine should remain the default interpreter engine, as it is by far the most portable engine, and even sometimes the fastest engine. But, I am all in favor of making SableJIT an official add-on that is released along SableVM, and set the build scripts so that a configure option would actually generate a SableVM+SableJIT combination (but not by default). So, in the long term, I do not see the /sablejit tree disappearing. I think that SableJIT should remain distributed separately in sablejit-x.y.z.tar.gz (where x.y.z matches sablevm's & sablevm-classpath's). 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-03-11 18:50:29
|
On Thu, Mar 11, 2004 at 10:04:09AM -0500, Etienne Gagnon wrote: > Grzegorz B. Prokopski wrote: > >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... >=20 > I do not want to see SableJIT code under the /sablevm project tree befo= re > the interface to the JIT is cleaned up and made into a minimal one, > instead of the "scattered all over the place" current status [unless I > am wrong and this has already been fixed]. It is getting smaller and smaller but not minimal yet. Agree with the SableJIT "add-on". David > I really want SableVM's source > code to remain as clean and easy to read/modify as possible. >=20 > I see SableJIT as an "add-on". It's source code should reside mostly > (i.e. 99,9%) under the /sablejit project tree. The additional 0.1% sho= uld > really be some very minimal changes in very few files (and very few pla= ces) > in SableVM's source code. >=20 > SableVM's inlined engine should remain the default interpreter engine, = as > it is by far the most portable engine, and even sometimes the fastest > engine. But, I am all in favor of making SableJIT an official add-on t= hat > is released along SableVM, and set the build scripts so that a configur= e > option would actually generate a SableVM+SableJIT combination (but not = by > default). >=20 > So, in the long term, I do not see the /sablejit tree disappearing. I = think > that SableJIT should remain distributed separately in sablejit-x.y.z.ta= r.gz > (where x.y.z matches sablevm's & sablevm-classpath's). >=20 > Etienne >=20 > --=20 > Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ >=20 >=20 > ------------------------------------------------------- > 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=3D1470&alloc_id=3D3638&op=3Dc= lick > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer --=20 --- 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X