Re: [Sablevm-developer] Warning: devel release approaching

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

Grzegorz B. Prokopski wrote:

> OTOH I think everybody agrees that we're in a need of release, so I am
> a bit inclined to loose the requirements *a little bit*, but it'd need
> to be evaluated on case-by-case basis. That's why I want to know what's
> the current state compared to old 1.0.9.

So, do you want me to do it then?  Or will you?

$ svn ls --username chris svn+ssh://svn.sablevm.org/public

does not work for me right now.  It was working last night without the 
username even ... so in the meantime if you have access it is faster for 
you to check 1.0.9.

> The words to remember: _regression tests_ start to be _required_

I think all actual functionality regressions should be eliminated before 
the release.

> Especially if we want to seriously treat our users (and ease our work in
> the long term). Temporarily we can use some proprietary benchmarks and
> the like for this purpose, but eventually - we should have a set of
> little but free tools that stretch the JVM in a few directions. Like
> BTF does it for inlined and architecture-specific problems (ex. in
> arithmetic and signal handling). Ex. Mauve is good, but it targetts
> more Classpath, not the JVM.


Have you looked at the JGF benchmarks yet?  It's not apparently GPL, 
LGPL, or public domain code, but the source is available.  I just sent 
them a mail about licensing.

JGF would be perfect to keep track of things like performance 
regressions as well.  Please download and run some of the benchmarks so 
that you see what I mean.

>>Not all of the JGF bugs seem like threading bugs.
> 
> 
> So we're even more in a need of nailing them down (at least documenting,
> possibly fixing).


I think we should focus on the JGFSyncBench bug and forget about the 
other stuff until that's fixed.  In my opinion, regardless of whether or 
not it's a regression, it's a serious bug -- the Java code that causes 
it is very simple.


>>I have some code comments that might be useful (e.g. in prepare_code.c, 
>>types.h ... stuff like that).
> 
> 
> Maybe at some point (not now) you should try to think about merging
> some of that? We already have some interesting things in sandboxes, but
> if nobody does the work required to make them ready for staging and 
> actually do the integration - these things just get older and don't
> benefit anybody (like hppa port I tried to ressurrect lately or Cygwin
> port in Melanie's sandbox).


So, I will make a tag for you that can be merged into staging, after we 
fix JGFSyncBench.

Chris