This is the mail archive of the mauve-discuss@sources.redhat.com mailing list for the Mauve project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bytecode test suite


Patrick Doyle wrote:

> I have started writing a test suite for the JVM itself, rather than
> the libraries; that is, I have a program which will run each
> bytecode under a variety of circumstances and make sure the result is
> correct.

Great. The main purpose of Mauve is tests of class
libraries, then it is not sufficient for testing JVM
festures. Such a test suite will get a welcome from
interpreter, JIT compiler and Java compiler writers.

> I'm thinking of starting a new project on SourceForge for this.

I have no idea on whether the new project should be
performed on the Mauve context or not.


> 2. Does anyone know of an existing bytecode test suite?  (I already found
> the one from the Mozilla project, and it's a good start, but it's not very
> thorough.)

AFAIK, the JCK (Java Compatibility Kit) is the richest
test suite. But I can't access it as you. It contains
thousands tests two or three years ago.  It has also a
framework for writing test code in Java bytecode, not
only Java language.

I have been looking for good test code because I have
been developing a JIT compiler. Of course, I have
written some test code by myself, but the followings are
the results of my investigation:

* gcc-3.0.

  Formerly, libgcj contained a test suite. The test suit
  seems to be incorporated into the gcc. The
  gcc-java-3.0.tar.gz archive contains many test code in
  the libjava/testsuite/ path.

* Kaffe.

  It has many regression tests in the test/regression/.

* JDK 1.1.6 and the priors.

  There were regression tests in the test/.


Additionally, I have used several softwares including
JDK demos, applets, benchmarks (SPEC JVM98,
CaffeineMark, SciMark 2, ...), IDE (NetBeans), javac and
so on.

But, there remains defects even those applications can
work well. For example, a volunteer applied the JCK to
our JIT compiler and reported some defects to me. One
defect is like this: the generated code for `aload'
instruction with `wide' prefix is not correct. This
instruction sequence is emitted in case that there are
over 255 local variables! We do not encounter such a
situation in daily life.
(But the JCK discoverd the defect.)


  Kazuyuki Shudo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]