Re: GCJ ------ file type not supported by system

[Pekka Enberg]

On Thu, Sep 4, 2014 at 11:15 PM, Andrew Haley  wrote:
> Everyone: let's have a proper discussion.  Is there something we can
> do with GNU Classpath that takes it further forward.  And, if so,
> what?  What would our goals be?

I think Guillermo is right that we need to update the GNU Classpath
web site. Right now, it gives the impression that the project is
abandoned...

- Pekka

Re: Re: GCJ ------ file type not supported by system

[Pekka Enberg]

El jueves, 4 de septiembre de 2014, Pekka Enberg  escribió:
>> No, it's really not unfair at all. You are basically saying Andrew is
>> doing a crappy job as a maintainer

On Thu, Sep 4, 2014 at 10:29 PM, Guillermo Rodriguez Garcia
 wrote:
> No, I am definitely NOT saying that, nothing even close. Please don't put
> your words in my mouth, thank you.

Of course you are saying that. Why else would you even bring up the
issue of finding a "competent successor" which implies that Andrew is
no longer interested in GNU Classpath and neglecting its maintenance?

El jueves, 4 de septiembre de 2014, Pekka Enberg  escribió:
>> Once you answer the hypothetical question *who* should
>> be the successor, you will understand why.

On Thu, Sep 4, 2014 at 10:29 PM, Guillermo Rodriguez Garcia
 wrote:
> I see, so if I don't have the answer, the question makes no sense. Ok.

You didn't even try to answer the question, did you?

If Andrew actually needed a "competent successor" (he doesn't), what
is required of that person? The person needs to be an active
developer, needs to understand GNU Classpath well, and has to have
support from people who actually developed the project, right?

Are you able to make an educated guess who actually meets that criteria?

- Pekka

Re: GCJ ------ file type not supported by system

[Pekka Enberg]

On Thu, Sep 4, 2014 at 7:17 PM, Guillermo Rodriguez
 wrote:
> I think that asking to "help rather than complain" is a bit unfair.

No, it's really not unfair at all. You are basically saying Andrew is
doing a crappy job as a maintainer when in reality he's pretty much
the only one developing GNU Classpath these days...

On Thu, Sep 4, 2014 at 7:17 PM, Guillermo Rodriguez
 wrote:
> First of all I am not "complaining", I am trying to suggest that perhaps,
> if time and resources are limited, the best way to spend them would be to
> look for a successor.

Thanks for the suggestion. We're going to just ignore it because it
makes no sense. Once you answer the hypothetical question *who* should
be the successor, you will understand why.

On Thu, Sep 4, 2014 at 7:17 PM, Guillermo Rodriguez
 wrote:
> Second, I am willing to help in any way I can, and already stated that.
> Yes I can submit patches (and will do) although in my opinion this does
> not address the underlying problem. I think that updating the website
> (to help raise awareness and attract developers) would be much more
> useful than sending patches to fix bugs or issues.

I also think the website needs fixing. Are sources to it available
somewhere and who is able to update it if someone actually sends a
patch against it?

- Pekka

Re: Building classpath on Minix3

[Pekka Enberg]

On Mon, Apr 8, 2013 at 2:47 PM, Alexander Samilovskih
 wrote:
> Trying to build
> ./autogen.sh
>
> configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not

[snip]

> -
> Google said that problem related to gettext, but i have it installed
> gettext --version
> gettext (GNU gettext-runtime) 0.18.1
> Copyright (C) 1995-1997, 2000-2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Written by Ulrich Drepper.

It's not enough that you have "gettext" installed, you also need to
make sure the following file exists:

/usr/share/aclocal/gettext.m4

On Fedora, for example, it's part of gettext-devel package that's not
installed by default.

Pekka

Re: Building GNU Classpath on Fedora 17

[Pekka Enberg]

On Tue, Mar 12, 2013 at 12:47 PM, Andrew Hughes  wrote:
> Looking at rpm -ql gettext-devel on my RHEL system, it seems to add a slew
> of m4 files to /usr/share/aclocal.  Maybe if -e /usr/share/aclocal/gettext.m4
> in autogen.sh would be sufficient?

The attached patch works for me. Does it look OK to commit?


0001-Check-for-gettext-in-autogen.sh.patch
Description: Binary data

Re: Building GNU Classpath on Fedora 17

[Pekka Enberg]

Hi Brian,

On Mon, Mar 11, 2013 at 4:41 PM, Brian Jones  wrote:
> Add a configure check for whatever the dependency is...

I'm having difficult time figuring out what to check for... It seems
that gettext-devel package provides AC_LIB_PREPARE_PREFIX via
/usr/share/aclocal/lib-prefix.m4 that's automagically picked up by
autogen.sh. Surely I can't just go and check if the file exists?

Pekka

Re: Building GNU Classpath on Fedora 17

[Pekka Enberg]

Hello,

On Mon, Mar 11, 2013 at 3:20 PM, Andrew Hughes  wrote:
> I wasn't aware we did.
>
> What version of libtool does F17 have?  I build with 2.4.2 at present.

Oh dear. I was missing gettext-devel package again! How can we add
some magic to "autogen.sh" to be more friendly to the user? I keep
hitting the same problem every time I try to build GNU Classpath on a
fresh installation... :-/

Pekka

Building GNU Classpath on Fedora 17

[Pekka Enberg]

Hello,

GNU Classpath build fails as follows with stock Fedora 17 libtools:

[penberg@golgotha classpath]$ sh autogen.sh
configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure:18624: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure:18625: error: possibly undefined macro: AC_LIB_RPATH
configure:18630: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY
configure:18638: error: possibly undefined macro: AC_LIB_APPENDTOVAR
autoreconf: /usr/bin/autoconf failed with exit status: 1

Is there any reason we depend on an older version of libtool?

Pekka

Object classinfo Mauve tests failing under GNU Classpath

[Pekka Enberg]

Hi Pavel,

I noticed two issues with your current Mauve classinfo test cases with
GNU Classpath.

  - I need the attached patch to make the Object classinfo tests run
with JamVM/GNU Classpath; otherwise I see syntax errors while Mauve
is trying to compile the test classes.

  - The tests in getMethods and getDeclaredMethods test cases are
incompatible with GNU Classpath for two reasons: GNU Classpath has
IllegalMonitorStateException in classfiles (which is arguably wrong)
and methods are not native in GNU Classpath like they are with
OpenJDK.

P.S. Can we migrate Mauve source code to a git repository, please?
Working with CVS is PITA.

Pekka


0001-Annotate-test-cases-that-require-JDK-1.5.patch
Description: Binary data

Re: Weirdness in native/jni/java-io/java_io_VMConsole.c

[Pekka Enberg]

On Thu, Mar 29, 2012 at 12:47 PM, Andrew Haley  wrote:
> There's a very odd comment in this file: it clearly refers to some
> method in another file.  But what was it for, anyway?  Surely the
> name of a method and its signature is contained in the code.  I'd just
> delete it.
>
> /*
>  * Class:     java_io_VMConsole
>  * Method:    echo
>  * Signature: (Z)Z
>  */
> JNIEXPORT jstring JNICALL
> Java_java_io_VMConsole_readPassword (JNIEnv * env,
>                                     jclass clazz
>                                     __attribute__ ((__unused__)),
>                                     jobject con)
> {

It's a copy-paste goof by me and I'm fine with dropping it. I only
added it to follow existing style.

Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...

[Pekka Enberg]

On Thu, Mar 29, 2012 at 6:40 PM, Andrew Haley  wrote:
> zebedee:classpath $ git push ssh://git.savannah.gnu.org/cgit/classpath.git/
> fatal: '/cgit/classpath.git' does not appear to be a git repository
> fatal: The remote end hung up unexpectedly
>
> Any idea what git wants to do the push?

Git wants the remote name. For example, I have:

penberg@jaguar:~/src/classpath$ git remote -v
icedtea git://icedtea.classpath.org/mirror/git/classpath/classpath (fetch)
icedtea git://icedtea.classpath.org/mirror/git/classpath/classpath (push)
origin  g...@github.com:penberg/classpath.git (fetch)
origin  g...@github.com:penberg/classpath.git (push)
savannahssh://git.sv.gnu.org/srv/git/classpath.git (fetch)
savannahssh://git.sv.gnu.org/srv/git/classpath.git (push)

so I use

  git push savannah master

You can add a new remote with

  git remote add savannah ssh://git.sv.gnu.org/srv/git/classpath.git

HTH

Pekka

Re: GNU Classpath 0.99 Released!

[Pekka Enberg]

On Fri, Mar 16, 2012 at 9:50 PM, Dr Andrew John Hughes
 wrote:
> We are proud to announce the release of GNU Classpath 0.99.

The web site doesn't mention the new release yet. How can we update it?

Re: GNU Classpath version control migration after .99?

[Pekka Enberg]

On Tue, Mar 20, 2012 at 12:28 AM, Andrew Hughes  wrote:
> As the deadline has now passed, I've populated the git repository on Savannah:
>
> http://git.savannah.gnu.org/cgit/classpath.git
>
> This is now the active development repository and the old CVS repository is 
> obsolete.

Yay! :-)

What APIs are missing from GNU Classpath?

[Pekka Enberg]

Hi,

I went through japitools results that compared GNU Classpath to Oracle
JDK and noticed that the following APIs are missing:

Java 1.5

- Lots of java.net APIs
- Pack200 format support

Java 1.6

- JDBC 4.0 API

Java 1.7

- NIO2 API
- Invokedynamic API

Anything else that I didn't spot?

Pekka

Re: GNU Classpath version control migration after .99?

[Pekka Enberg]

On Mon, Mar 12, 2012 at 10:00 PM, Andrew Hughes  wrote:
> Well, you probably know from
>
> http://developer.classpath.org/pipermail/classpath/2012-March/003180.html
>
> that I'm in favour of a move to git sooner rather than later.
>
> How about we give it a week from now (say Monday 19th, 16h00 UTC), and if 
> there
> are no objections, we push the existing IcedTea mirror to the Classpath 
> Savannah
> project and start using that?

I'm obviously happy with that.

Pekka

GNU Classpath version control migration after .99?

[Pekka Enberg]

Hello,

0.99 is almost out of the door so I'd like to begin the discussion on
version control migration. AFAICT, we've all agreed that we'll dump
CVS but left the decision open to which tool we'll migrate.

What I'd personally like to see is that once 0.99 is out, we shut down
CVS, convert the git mirrors to read-write git repositories:

http://icedtea.classpath.org/mirror/git

and keep the existing Mercurial mirroring scripts in place.

Thoughts?

Pekka

Re: 0.99 Release

[Pekka Enberg]

On Wed, Feb 1, 2012 at 6:33 PM, Andrew Hughes  wrote:
> There are a lot of unreleased fixes in there, including these latest locale
> improvements.

JRuby and Jython won't even start up with .98 so I'm definitely for .99 release!

[ANNOUNCE] Jato 0.3

[Pekka Enberg]

h
  jit: Add abc-removal
  jit: Fix bug in insert_list
  jit: Compute natural loops
  jit: Enable SSA only when abc elimination needed
  Documentation: Add SSA documentation

Ankit Laddha (38):
  arm: Add stub methods so 'make check' links
  arm: Fix unit tests on ARM
  arm: Add stubs required for IC and SSA projects
  arm: Framework so arm porting can start
  arm: conversion of EXPR_VALUE to LIR
  arm: Stubs required for SSA project
  arm: Convert EXPR_LOCAL to LIR
  arm: Encoding of reg_imm_insn and reg_memlocal_insn
  arm: Framework so that bytecode-test run on arm
  arm: fix the broken unit test
  arm: Add stubs required for SSA project
  arm: Fix encoding of reg_memlocal_insn
  arm: Convert STMT_RETURN and VOID_RETURN to LIR
  arm: Fix the flow of process of encoding insns
  arm: Encode INSN_MOV_REG_REG
  arm: Encode INSN_UNCOND_BRANCH
  arm: Change memory read function
  arm: Emit the prolog of a function
  arm: Emit epilog of a function
  arm: Implement functions for liveness analysis
  arm: Emission of trampoline started
  arm: Funtion implementation for register allocation
  arm: Configured IC calls for ARM
  arm: set the text alignment in the execution pages
  arm: Full trampoline support emitted
  arm: Fix bug in trampoline emission
  arm: Initial support for bytecode tests
  arm: Some more bytecode-tests running successfully
  arm: change one LIR instruction
  arm: LIR conversion for STMT_STORE
  arm: Emit INSN_STORE_MEMLOCAL_REG
  arm: fixup instruction mnemonics
  arm: Support for negative integers
  arm: Add support for addition of integers
  arm: Add more rules to insn selector
  arm: Support for subtraction
  arm: Pass more bytecode tests
  test, integration: reordering the test cases

Balagopal (10):
  jit: Support for multiple entry points to methods.
  x86: Inline cache with clean and monomorphic states for INVOKEVIRTUAL.
  x86: Inline cache cleanups
  x86: Fix compile errors on x86_64
  x86: Megamorphic inline cache on x86_32
  test/functional: Modify invokevirtual test for better coverage.
  x86: Add dummy ic_vcall_stub for x86_64
  Makefile: Framework to generate asm-offsets
  test: Added microbenchmark for measuring Inline cache performance.
  jit: Added -Xnoic to disable inline caching

Joonas Reynders (4):
  vm: Convert classloader trace level to use pthread API
  vm, gc: Convert gc safepoint flag to use pthread API
  Converts trace_buffer from __thread to pthread API
  Convert signal register_state variable from __thread to pthread API

Nikhil Sarda (5):
  reflection: Fix parameter annotation test
  jit: Make check was failing with a SIGSEGV.
  test/integration: Added some more bytecode tests.
  test/integration: Added bytecode tests for istore, lstore, fstore and 
dstore.
  vm, gc: Improved error handling.

Pekka Enberg (219):
  vm: Fix VM launcher help text
  test/functional: Fix broken IsInstanceOf JNI test case
  test/functional: Disable parameter annotation tests
  Makefile: Fix 'tags' target to include sys directory
  arm: Fix 'make check' error caused by missing target
  test/integration: Fix printf format string error
  vm: Fix current_exec_env_key definition
  lib: Add arena memory allocator
  jit: Use arena allocator for struct var_info and friends
  x86: Fix do_native_call() miscompilation with '-O3'
  Makefile: Use GCC '-O3' optimization level
  Makefile: Use -fno-tree-vectorize on x86-64
  jit: Optimize interval_expire_ranges_before() and interval_range_at()
  vm: Optimize vm_class_is_assignable_from()
  vm: Make subtype checking faster
  test, unit: Fix compilation error
  Revert "vm: Make subtype checking faster"
  Makefile: Revert back to -Os for 32-bit
  vm: Add '-XX:+PrintCompilation' command line option
  test/functional: Rename FieldTest to FieldAccessorsTest
  runtime: Fix VMClass accessor method compatibility issues
  test/functional: Enable more test cases in FieldAccessorsTest
  runtime: Use java_lang_reflect_VMField prefix for native functions
  vm, runtime: Move VMField functions to runtime/java_lang_reflect_VMField.c
  reflection: Fix VMField.get() from superclasses
  jit: Fix uninitialized variable use in analyze_control_flow()
  vm: Merge 'enum thread_state' to 'enum vm_thread_state'
  jit: Cleanup jit/compilation-unit.c
  vm: Add interpreter for OPC_NOP and OPC_RETURN
  x86: Fix printf format on 64-bit
  x86-64: Kill broken OP_CMP rule from insn selector
  x86-64: Fix EXPR_FLOAT_CLASS_FIELD args on stack
  x86: Fix asm-offsets.c
  x86-64: Fix STMT_STORE args on stack
  x86-64: 

Re: Experimental GNU Classpath and Mauve mercurial and git mirrors

[Pekka Enberg]

On Mon, Oct 10, 2011 at 12:04 PM, Mark Wielaard  wrote:
> Thanks to Pekka Enberg there are now experimental hg and git mirrors of
> all the GNU Classpath and Mauve CVS repository modules on icedtea:
> http://icedtea.classpath.org/mirror/hg/
> http://icedtea.classpath.org/mirror/git/
>
> They should sync each hour and update.

Yay! Thanks for setting this up, Mark.

Re: [problem] GNU Classpath build problems on Fedora 15

[Pekka Enberg]

On Thu, Sep 29, 2011 at 2:54 PM, Mark Wielaard  wrote:
> It seems gnulib also provides lib-prefix.m4 in the havelib module. Maybe
> we should just incorporate it from there and not depend on gettext-devel
> to be installed (I am a bit fuzzy on why we have the
> gettext-devel/lib-prefix.m4 dependency, we only really need iconv
> support, but there was some dependency on gettext anyway)?

It seems we had lib-prefix-m4 in the tree but Andrew dropped it:

2010-01-30  Andrew John Hughes  

* autogen.sh:
Allow libtool 2.* through.
* configure.ac:
Updated via autoupdate.
* m4/lib-ld.m4,
* m4/lib-link.m4,
* m4/lib-prefix.m4:
Drop old libtool macros which
result in build failure.

Hmmh?

Pekka

Re: [problem] GNU Classpath build problems on Fedora 15

[Pekka Enberg]

> On Tue, 2011-09-27 at 15:31 +0300, Pekka Enberg wrote:
>> I'm seeing this on Fedora 15:
>>
>> [penberg@tux classpath.cvs]$ sh autogen.sh
>> configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
>> not m4_defun'd
>> m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
>> m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
>> m4/iconv.m4:77: AM_ICONV is expanded from...
>> configure.ac:505: the top level
>> configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
>> m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
>> m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
>> m4/iconv.m4:77: AM_ICONV is expanded from...
>> configure.ac:505: the top level

On Thu, Sep 29, 2011 at 12:52 PM, Mark Wielaard  wrote:
> I don't have my F15 setup handy, but I think this is missing
> iconv/gettext m4 macros. Try installing gettext-devel which should
> provide /usr/share/aclocal/lib-prefix.m4

Gee, it's that again. Yeah, it helped. Thanks!

> If that helps we should probably update the INSTALL and/or autogen.sh
> checks.

I'll do that. I guess we can just do:

+if [ -e "/usr/share/aclocal/lib-prefix.m4" ] ; then
+   have_gettext=true
+fi

right?

Pekka

Re: [problem] GNU Classpath build problems on Fedora 15

[Pekka Enberg]

On Thu, Sep 29, 2011 at 2:20 AM, Dr Andrew John Hughes
 wrote:
> No. Can you give the versions of the autotools on this platform?  That would
> be more generally useful.  It's likely to be that something has been updated.
>
> Personally, I have autoconf 2.68, automake 1.11.1 and libtool 2.4 here on 
> Gentoo.

Strange. I have the exact same versions:

[penberg@tux ~]$ autoconf --version
autoconf (GNU Autoconf) 2.68
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
, 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
[penberg@tux ~]$ automake --version
automake (GNU automake) 1.11.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey 
   and Alexandre Duret-Lutz .
[penberg@tux ~]$ libtool --version
libtool (GNU libtool) 2.4
Written by Gordon Matzigkeit , 1996

Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

What else could it be? I have m4 1.4.16 here:

[penberg@tux classpath.git]$ m4 --version
m4 (GNU M4) 1.4.16

Pekka

[problem] GNU Classpath build problems on Fedora 15

[Pekka Enberg]

Hi all,

I'm seeing this on Fedora 15:

[penberg@tux classpath.cvs]$ sh autogen.sh
configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:505: the top level
configure:18566: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure:18567: error: possibly undefined macro: AC_LIB_RPATH
configure:18572: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY
configure:18580: error: possibly undefined macro: AC_LIB_APPENDTOVAR
autoreconf: /usr/bin/autoconf failed with exit status: 1

Has anyone built GNU Classpath on Fedora 15 successfully?

   Pekka

Re: Using ASM for invokedynamic bytecode generation

[Pekka Enberg]

Hi Mark,

On Thu, Sep 8, 2011 at 10:33 PM, Mark Wielaard  wrote:
> I don't know much about what is needed for invoke dynamic byte code
> generation. Note that java/lang/reflect/Proxy.java for example also can
> generate byte code, but just does it by hand. Is such an approach
> possible?

It's possible, sure. I was thinking of using ASM because I suspect the
generated bytecode won't be trivial. I'll see how quickly I hit limitations
with generating bytecode by hand. Is a light-weight GNU Classpath
specific bytecode helper API totally out of the question?

Pekka

Using ASM for invokedynamic bytecode generation

[Pekka Enberg]

Hi all,

I started hacking on invokedynamic again:

https://github.com/penberg/classpath/commit/21c457f4928678bb5709dfc5a992b80f0d02c4b8

https://github.com/penberg/jato/commits/indy

I'm planning to use ASM for generating bytecode for method handle
chains. Does that sound like a reasonable thing to do? We already
carry the ASM code under tools/external/asm/. Can I just move that
under external/ and rename the package so that it doesn't clash with
the upstream project?

Pekka

Re: [PROBLEM] Building GNU Classpath on Darwin

[Pekka Enberg]

On Tue, Jul 5, 2011 at 12:53 PM, Mark Wielaard  wrote:
> Hi Pekka,
>
> On Tue, 2011-07-05 at 12:28 +0300, Pekka Enberg wrote:
>> I'm trying to build GNU Classpath CVS HEAD on Mac OS X 10.6.7. I
>> followed these instructions to satisfy the autoconf 2.65 requirement:
>>
>> http://www.mattvsworld.com/blog/2010/02/install-the-latest-autoconf-and-automake-on-mac-os-10-6/
>>
>> However, when I try to run 'autogen.sh' I get the following error:
>>
>> $ sh autogen.sh
>> configure.ac:503: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
>> not m4_defun'd
>> m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
>> m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
>> m4/iconv.m4:77: AM_ICONV is expanded from...
>> configure.ac:503: the top level
> [...]
>> autoreconf: /usr/local/bin/autoconf failed with exit status: 1
>>
>> Any ideas what's going wrong here?
>
> I am not sure, but you might be missing gettext, and our configure picks
> up the local m4/iconv.m4. We don't actually use gettext, but we try to
> use iconv. See the installation instructions at
> http://www.gnu.org/software/libiconv/ which has a little section on
> iconv.m4. So try installing gettext, or find an updated version of the
> libiconv iconv.m4 and install that under the classpath/m4/ directory.
> Please let us know if that helps or not.

I had gettext installed but I had to do 'brew link' on it:

  sudo brew link gettext

for it to become visible in PATH. After I did that, autogen.sh started
working. I wonder why the error message is so darn cryptic, though...
;-)

Anyway, thanks!

[PROBLEM] Building GNU Classpath on Darwin

[Pekka Enberg]

Hi,

I'm trying to build GNU Classpath CVS HEAD on Mac OS X 10.6.7. I
followed these instructions to satisfy the autoconf 2.65 requirement:

http://www.mattvsworld.com/blog/2010/02/install-the-latest-autoconf-and-automake-on-mac-os-10-6/

However, when I try to run 'autogen.sh' I get the following error:

$ sh autogen.sh
configure.ac:503: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:503: the top level
configure.ac:503: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
configure.ac:503: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:503: the top level
configure.ac:503: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:503: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:503: the top level
configure.ac:503: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
configure.ac:503: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but
not m4_defun'd
m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
m4/iconv.m4:77: AM_ICONV is expanded from...
configure.ac:503: the top level
configure.ac:503: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd
configure:17858: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure:17859: error: possibly undefined macro: AC_LIB_RPATH
configure:17864: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY
configure:17872: error: possibly undefined macro: AC_LIB_APPENDTOVAR
autoreconf: /usr/local/bin/autoconf failed with exit status: 1

Any ideas what's going wrong here?

   Pekka

[ANNOUNCE] Jato v0.2 - a JIT-only virtual machine for Java

[Pekka Enberg]

Hi all!

Jato 0.2 release is now available!

Jato is an open source, JIT-only virtual machine for Java that aims to support
the latest JVM specification. It can currently run many Java applications on
32-bit x86 Linux machines such as Eclipse.

What's new in this release:

  - Jython and JRuby start up under the VM (requires GNU Classpath CVS HEAD)

  - Annotation support (Pekka Enberg, Nikhil Sarda)

  - More missing JNI APIs implemented (Joonas Reynders, Nikhil Sarda)

  - More missing reflection APIs implemented (Nikhil Sarda)

  - Linux/x86-64 port fixes (Eduard - Gabriel Munteanu, Sergey Mashkov, Pekka 
Enberg)

  - Linux/i386 bug fixes (Tomek Grabiec, Vegard Nossum)

  - SSA form bug fixes (Ana-Maria Farcasi)

  - Darwin port fixes (Michael Tremel)

NOTE NOTE NOTE! You're strongly encouraged to use GNU Classpath CVS HEAD
because it has important Jython and JRuby compatibility fixes that are not part
of any release.

There's a Github mirrof the GNU Classpath here for people who don't want to use
CVS:

  https://github.com/penberg/classpath

The source code for Jato is available for download here:

   http://www.kernel.org/pub/software/java/jato/jato-0.2.tar.bz2

You can also get the latest sources from the git repository:

   git clone git://git.kernel.org/pub/scm/java/jato/jato.git

If you have questions, comments, or suggestions, feel free to drop by at #jato
on irc.freenode.net or send an email to our mailing list at:

   http://groups.google.com/group/jatovm?hl=en

You can also report problems on Github:

  https://github.com/penberg/jato/issues

For more information, please check out the Jato home page:

   http://www.jatovm.org/

Pekka
---

Changes from v0.1.1 to v0.2: 


Ana Farcasi (3):
  jit: fix initialization of a compilation unit
  test/unit: Added test for dominance frontier sets
  arch/x86: Fix print_jmp_memindex

Ankit Laddha (1):
  arm: Add dummy functions to make Jato link on ARM

Balagopal (1):
  vm: Add option -Xtrace:vtable for tracing all vtables

Eduard - Gabriel Munteanu (9):
  x86-64: fix unwind emitter
  Add DEBUG option to the build system.
  New section on GDB support in Documentation/debugging.txt
  Discover GNU Classpath 0.98 on Gentoo
  x86-64: handle 32-bit imm movs
  x86-64: set the vm_type in args_map_assign()
  x86-64: fix regparm allocation for JNI arguments
  x86-64: fix float / double returns
  x86-64: fix invoke result propagation for float / double

Farcasi Ana-Maria (4):
  jit: Fix crash in do_compute_dfns()
  vm: Fix -Xssa command line option parsing
  jit: Add tracing for SSA data structures
  x86: fix print_jmp_membase

Joonas Reynders (36):
  runtime: Implement VMRuntime#traceMethodCalls
  tests: Introduce JNI test case
  Added JNI roundtrip tests for basic types. Float and double fail
  jni,test: Add basic instance roundtrip test to JNITest
  jni,test: Add JNI array types and roundtrip tests
  jni: Convert part of the JNI API to correspond the JNI spec
  JNI refactoring, jnienv methods 26-34
  JNI CallXxxMethod-function names refactored to spec
  JNI CallNonvirtualXxxMethod-function names refactored to spec
  jni get and set field method names refactored according to spec
  JNI call static method function names refactored according to spec
  jni: JNI_{Get|Set}Static*Field API refactoring
  JNI function names 164-175 refactored according to spec
  Refactor the remaining JNI 1.1 function names
  JNI 1.2 and forward function names refactored according to spec
  Final refactoring of JNI functions, jvalue and const fixes
  jni: Refactor java_vm to JavaVM as per JNI specification
  Functional test for JNI GetVersion
  vm,jni: Moved Java and JNI version constants to java-version.h
  Remove unused JNI guard page mechanism
  vm: Fix defaultJNIEnv initialization and add test
  vm,jni: JNI_DefineClass implementation and test
  test/functional: Fixed java formatting
  test/functional: Add JNI FindClass tests
  Add a simple functional test for broken class files
  vm: Add debug printing functions
  runtime: java.lang.reflect.Method support for ToReflectedMethod and 
FromReflectedMethod
  runtime: java.lang.reflect.Field support for JNI ToReflectedField and 
FromReflectedField
  vm: java.lang.Object support for debug printing
  runtime: Move struct vm_method helpers to reflection.c
  runtime: Refactor vm_field to java.lang.reflect.Field wrapping
  jni: JNI GetSuperclass implementation and tests
  test/functional: Add tests for JNI isAssignableFrom
  test/functional: Add tests for JNI Throw function
  test/functional: Add tests for JNI ThrowNew function
  test/functional: Add tests for JNI ExceptionOccurred and ExceptionClear 
functions

Karim Osman (1):
  Update README file

Michael 

Re: [RFC/PATCH] Invokedynamic API stubs

[Pekka Enberg]

Hi Mark,

On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote:
>> > > I guess I could keep it on my Github mirror until I have something
>> > > concrete enough to be merged to trunk.
>> > >
>> > I'd prefer to have it in HEAD as long as it's clearly marked as stubs
>> > (the NotImplementedException I mentioned) and there is work actively
>> > taking place.
>> > Then there's always the (slim) possibility someone else can work on it :-)

On Mon, 2011-02-07 at 22:01 +0200, Pekka Enberg wrote:
>> That was my original thinking as well. Does the included patch look
>> better to you? Mark, what do you think about this?

On Tue, Feb 8, 2011 at 2:28 PM, Mark Wielaard  wrote:
> I admit to still just not like stubs, however they are setup.
> If creating branches wasn't such a pain with CVS I would really
> recommend doing all this on a branch and only merge when ready and it
> can actually be used with some VM. I guess it is just time to bite the
> bullet and create some time to move to mercurial and setup some rules
> about how to create working branches. I won't veto getting this in right
> now if that is really what you and Andrew want, but I am not
> particularly excited either.

Well, I'd like to keep everyone involved excited so maybe Mercural
branch is the way to go here?

Pekka

Re: [RFC/PATCH] Invokedynamic API stubs

[Pekka Enberg]

On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote:
> > I guess I could keep it on my Github mirror until I have something
> > concrete enough to be merged to trunk.
> >
> I'd prefer to have it in HEAD as long as it's clearly marked as stubs
> (the NotImplementedException I mentioned) and there is work actively
> taking place.
> Then there's always the (slim) possibility someone else can work on it :-)

That was my original thinking as well. Does the included patch look
better to you? Mark, what do you think about this?

Pekka

>From 81362427a842e815bfe354036cd4201ee781880a Mon Sep 17 00:00:00 2001
From: Pekka Enberg 
Date: Thu, 3 Feb 2011 16:29:15 +0200
Subject: [PATCH] Invokedynamic API stubs

This patch implements the work-in-progress invokedynamic API stubs described
here:

  http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html

The classes don't do anything useful yet and don't even contain all the
specified methods.

Signed-off-by: Pekka Enberg 
---
 java/dyn/BootstrapMethod.java |   52 
 java/dyn/CallSite.java|   60 
 java/dyn/ClassValue.java  |   45 +
 java/dyn/ConstantCallSite.java|   46 +
 java/dyn/InvokeDynamic.java   |   49 +++
 java/dyn/InvokeDynamicBootstrapError.java |   47 ++
 java/dyn/Linkage.java |   45 +
 java/dyn/LinkagePermission.java   |   56 ++
 java/dyn/MethodHandle.java|   62 +
 java/dyn/MethodHandleProvider.java|   52 
 java/dyn/MethodHandles.java   |   52 
 java/dyn/MethodType.java  |   50 +++
 java/dyn/NoAccessException.java   |   47 ++
 java/dyn/WrongMethodTypeException.java|   47 ++
 14 files changed, 710 insertions(+), 0 deletions(-)
 create mode 100644 java/dyn/BootstrapMethod.java
 create mode 100644 java/dyn/CallSite.java
 create mode 100644 java/dyn/ClassValue.java
 create mode 100644 java/dyn/ConstantCallSite.java
 create mode 100644 java/dyn/InvokeDynamic.java
 create mode 100644 java/dyn/InvokeDynamicBootstrapError.java
 create mode 100644 java/dyn/Linkage.java
 create mode 100644 java/dyn/LinkagePermission.java
 create mode 100644 java/dyn/MethodHandle.java
 create mode 100644 java/dyn/MethodHandleProvider.java
 create mode 100644 java/dyn/MethodHandles.java
 create mode 100644 java/dyn/MethodType.java
 create mode 100644 java/dyn/NoAccessException.java
 create mode 100644 java/dyn/WrongMethodTypeException.java

diff --git a/java/dyn/BootstrapMethod.java b/java/dyn/BootstrapMethod.java
new file mode 100644
index 000..d2ec24a
--- /dev/null
+++ b/java/dyn/BootstrapMethod.java
@@ -0,0 +1,52 @@
+/* BootstrapMethod.java --
+   Copyright (C) 2011 Free Software Foundation
+
+This file is part of GNU Classpath.
+
+GNU Classpath is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Classpath is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Classpath; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version. */
+
+package java.dyn;
+
+import java.lang.annotation.Retention;
+import java.lang.annotation.Target;
+import static java.lang.annotation.RetentionPoli

Re: [RFC/PATCH] Invokedynamic API stubs

[Pekka Enberg]

Hi!

On Thu, 2011-02-03 at 16:47 +0200, Pekka Enberg wrote:
>> I'd like to check in these simple invokedynamic API stubs into CVS HEAD.
>> The APIs are not final but I think now is as good time as any to start
>> working on them especially as it needs work on the VM side. Furthermore,
>> there's already open source projects such as JRuby out there that use
>> invokedynamic so I think GNU Classpath probably needs to support it at
>> some point anyway.
>
>> The classes don't do anything useful yet and don't even contain all
>> the specified methods.

On Fri, Feb 4, 2011 at 10:11 AM, Mark Wielaard  wrote:
> I have to admit that I don't like putting in stubs. In the past we have
> decided to just leave things really unimplemented if we don't support
> it. And as you say it needs a bit more design thinking. So I would
> suggest you do this on a branch first (grmbl CVS...) and/or first try to
> spec it out against a jato VM implementation.

Sure, I want to start looking at implementing invokedynamic for Jato
which is why I implemented these stubs in the first place. I expect
that to take some time so the question is where to put the
work-in-progress implementation. I don't see any reason to keep it
stashed on my local hard disk but I have to admit I'm not entirely
happy with the idea of using CVS branches for it either...

I guess I could keep it on my Github mirror until I have something
concrete enough to be merged to trunk.

On Fri, Feb 4, 2011 at 10:11 AM, Mark Wielaard  wrote:
> BTW. John Rose has lots of background material online:
> http://cr.openjdk.java.net/~jrose/pres/

Thanks!

Pekka

[RFC/PATCH] Invokedynamic API stubs

[Pekka Enberg]

Hi!

I'd like to check in these simple invokedynamic API stubs into CVS HEAD.
The APIs are not final but I think now is as good time as any to start
working on them especially as it needs work on the VM side. Furthermore,
there's already open source projects such as JRuby out there that use
invokedynamic so I think GNU Classpath probably needs to support it at
some point anyway.

Pekka

>From 6dca9b60d6c2380164920e40302f08616a6874b6 Mon Sep 17 00:00:00 2001
From: Pekka Enberg 
Date: Thu, 3 Feb 2011 16:47:15 +0200
Subject: [PATCH] Invokedynamic API stubs

This patch implements the work-in-progress invokedynamic API stubs described
here:

  http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html

The classes don't do anything useful yet and don't even contain all the
specified methods.

Signed-off-by: Pekka Enberg 
---
 java/lang/dyn/BootstrapMethod.java |   52 +
 java/lang/dyn/CallSite.java|   57 +++
 java/lang/dyn/ClassValue.java  |   45 ++
 java/lang/dyn/ConstantCallSite.java|   46 ++
 java/lang/dyn/InvokeDynamic.java   |   49 
 java/lang/dyn/InvokeDynamicBootstrapError.java |   47 +++
 java/lang/dyn/Linkage.java |   45 ++
 java/lang/dyn/LinkagePermission.java   |   55 ++
 java/lang/dyn/MethodHandle.java|   59 
 java/lang/dyn/MethodHandleProvider.java|   52 +
 java/lang/dyn/MethodHandles.java   |   52 +
 java/lang/dyn/MethodType.java  |   50 
 java/lang/dyn/NoAccessException.java   |   47 +++
 java/lang/dyn/WrongMethodTypeException.java|   47 +++
 14 files changed, 703 insertions(+), 0 deletions(-)
 create mode 100644 java/lang/dyn/BootstrapMethod.java
 create mode 100644 java/lang/dyn/CallSite.java
 create mode 100644 java/lang/dyn/ClassValue.java
 create mode 100644 java/lang/dyn/ConstantCallSite.java
 create mode 100644 java/lang/dyn/InvokeDynamic.java
 create mode 100644 java/lang/dyn/InvokeDynamicBootstrapError.java
 create mode 100644 java/lang/dyn/Linkage.java
 create mode 100644 java/lang/dyn/LinkagePermission.java
 create mode 100644 java/lang/dyn/MethodHandle.java
 create mode 100644 java/lang/dyn/MethodHandleProvider.java
 create mode 100644 java/lang/dyn/MethodHandles.java
 create mode 100644 java/lang/dyn/MethodType.java
 create mode 100644 java/lang/dyn/NoAccessException.java
 create mode 100644 java/lang/dyn/WrongMethodTypeException.java

diff --git a/java/lang/dyn/BootstrapMethod.java 
b/java/lang/dyn/BootstrapMethod.java
new file mode 100644
index 000..d2ec24a
--- /dev/null
+++ b/java/lang/dyn/BootstrapMethod.java
@@ -0,0 +1,52 @@
+/* BootstrapMethod.java --
+   Copyright (C) 2011 Free Software Foundation
+
+This file is part of GNU Classpath.
+
+GNU Classpath is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Classpath is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Classpath; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version. */
+
+package java.dyn;
+
+import java.lang.annotation.Retention;
+import java.lang.annotation.Target;
+import static java.lang.annotation.RetentionPolicy.SOURCE;
+import static java.lang.annotation.ElementType.*;
+
+/**
+ * @since 1.7
+ */
+@T

Re: gij: unrecognized option -- `-o'

[Pekka Enberg]

On Thu, Dec 16, 2010 at 12:36 PM, Andrew Haley  wrote:
> On 05/19/2010 09:13 PM, KessiMC wrote:
>>
>> Hi everyone
>>
>> Having finally become somewhat more confident in trying to cross-compile
>> GNU
>> Classpath, I dastardly failed on my most recent attempt with the following
>> error message:
>>
>> Making all in tools
>> make[1]: Entering directory `/opt/C++/classpath/classpath-build/tools'
>> /bin/mkdir -p classes asm
>> /bin/mkdir -p ../tools/generated/gnu/classpath/tools/gjdoc/expr
>> gij -classpath  antlr.Tool -o
>> ../tools/generated/gnu/classpath/tools/gjdoc/expr/ \
>>
>>
>> ../../classpath-0.98/tools/gnu/classpath/tools/gjdoc/expr/java-expression.g
>> gij: unrecognized option -- `-o'
>
> -classpath needs an argument.  It should be the path to the ANTLR jarfile.

IIRC, I fixed this locally by installing native antlr package.

Re: Future blog

[Pekka Enberg]

On Thu, 2010-12-09 at 12:45 +, Dr Andrew John Hughes wrote:
> I disagree.  Just because the version in gcj is different doesn't mean
> it's correct.  As far as I'm aware, Pekka already has a testcase for
> this so it would be good to have it in Mauve.

Sorry for the delay, here's a test case for getSimpleName().

Pekka

>From 3637ab8ec4f866da6fadc092eab1f99ce4adb417 Mon Sep 17 00:00:00 2001
From: Pekka Enberg 
Date: Sun, 12 Dec 2010 10:52:27 +0200
Subject: [PATCH] mauve: Add test case for Class.getSimpleName()

Signed-off-by: Pekka Enberg 
---
 gnu/testlet/java/lang/Class/ClassTest.java |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/gnu/testlet/java/lang/Class/ClassTest.java 
b/gnu/testlet/java/lang/Class/ClassTest.java
index 71b144c..c5927e8 100644
--- a/gnu/testlet/java/lang/Class/ClassTest.java
+++ b/gnu/testlet/java/lang/Class/ClassTest.java
@@ -577,6 +577,18 @@ public class ClassTest implements Cloneable, 
java.io.Serializable, Testlet
 harness.check(in == null);
   }
 
+  public void test_getSimpleName()
+  {
+harness.checkPoint("test_getSimpleName");
+harness.check(int.class.getSimpleName().equals("int"));
+harness.check(int[].class.getSimpleName().equals("int[]"));
+harness.check(int[][].class.getSimpleName().equals("int[][]"));
+harness.check(Object[].class.getSimpleName().equals("Object[]"));
+harness.check(Object.class.getSimpleName().equals("Object"));
+harness.check(InnerClass.class.getSimpleName().equals("InnerClass"));
+  }
+  public static class InnerClass { };
+
   public void testall()
   {
 test_toString();
@@ -594,6 +606,7 @@ public class ClassTest implements Cloneable, 
java.io.Serializable, Testlet
 // This one doesn't work so well in Mauve.
 // test_getResource();
 test_getResourceAsStream();
+test_getSimpleName();
 
   }
 
-- 
1.7.0.4

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 2:03 PM, Andrew Haley  wrote:
>> No need to live with it, I'll fix it up and resend.
>
> This is truly weird.  The gcj patch says:
>
> 2008-05-22  Andrew Haley  
>
>        PR libgcj/35020
>        * java/lang/Class.java (getSimpleName): Import from GNU Classpath.
>
> http://gcc.gnu.org/ml/java-patches/2008-q2/msg00016.html
>
> There's a complex thread of replies to that.  Still, I'm pretty
> sure the current gcj version is right.

I didn't check gcj code but lifted the copy from JamVM. The issues is
bit weird for sure as it's been ongoing for ages now:

http://www.mail-archive.com/classpath-patc...@gnu.org/msg10757.html

http://draenog.blogspot.com/2009/03/i-read-with-interest-jeroens-recent.html

In any case, the test case I mentioned passes with OpenJDK and fails
with Classpath CVS unless I apply the patch I sent.

Pekka

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:47 PM, Andrew Haley  wrote:
>> That the result is not what we get with OpenJDK. JamVM, for example,
>> (and I guess CACAO) has fixed this in their tree as has GCJ. The test
>> case I used for this is ClassTest.testGetSimpleName() here:
>>
>> https://github.com/penberg/malva/blob/master/src/malva/java/lang/ClassTest.java
>
> The patch is OK.
>
> I'm not sure about this bit, but I can live with it:

No need to live with it, I'll fix it up and resend.

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:41 PM, Andrew Haley  wrote:
>> I'm not sure if this is all of it but it's a start anyway:
>>
>> http://developer.classpath.org/pipermail/classpath-patches/2010-June/006411.html
>
> Ah, yes, these were the patches that were sent hex encoded with a
> MIME type of application/octet-stream.  Needless to say these didn't
> get reviewed.

Right.

> I'll have a look, but IMO it is unreaslistic to expect a reviewer to
> save an attachment and open it in an external editor.  And I did point
> this out at the time.

I completely agree. I have Ivan's patches locally and I'm planning to
go through them and resend them to the list unless he beats me to it.

   Pekka

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:13 PM, Andrew Haley  wrote:
>> http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html
>
> What compatibility problem does this fix?

That the result is not what we get with OpenJDK. JamVM, for example,
(and I guess CACAO) has fixed this in their tree as has GCJ. The test
case I used for this is ClassTest.testGetSimpleName() here:

https://github.com/penberg/malva/blob/master/src/malva/java/lang/ClassTest.java

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:13 PM, Andrew Haley  wrote:
>> There's also 10-15 patches from Ivan sitting in the archives
>
> Hmm, I had seen some discussion around those and thought they were being
> addressed.  Bring them on!

I'm not sure if this is all of it but it's a start anyway:

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006411.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006424.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006437.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006438.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006441.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006439.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006440.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006442.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006443.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006444.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006445.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006446.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006447.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006448.html

Re: Future blog

[Pekka Enberg]

Hi Andrew,

On Wed, Dec 8, 2010 at 1:06 PM, Andrew Haley  wrote:
> On 12/08/2010 10:56 AM, Pekka Enberg wrote:
>> On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley  wrote:
>>> Anyway, I don't mind that as long as someone else does it.  (Clearly,
>>> the issue of developers without commit access is a red herring, as
>>> every developer should have commit access.)
>>
>> But it's not a red herring! I don't expect to have commit rights to
>> GNU Classpath. I'm more than happy to send patches to the list and
>> have someone else merge them (that's in fact a model I personally
>> prefer).
>
> This model does not scale.  Also, it is unreliable: no-one should
> commit a patch they haven't tested themselves.  It leads to extra
> work.  It's also bad because it leads to two classes of developers,
> those with and those without commit access.

Well, you know, it works just fine for the Linux kernel so as a
general statement, that's just not true.

> Every developer should commit their own patches.

I didn't mean to start an argument on what kind of development model
GNU Classpath should be using. But I don't quite agree with the above
statement because waiting for commit access creates a barrier for
people who just want to submit simple one-liners. In any case, even if
everyone did have commit access, CVS is still painful for *local*
development.

Pekka

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley  wrote:
> But I'm afraid people are looking at the things they think might make
> a difference, but won't make a difference.  I read the list, and
> haven't seen a huge number of unreviewed patches, but I admit I
> haven't been paying close enough attention.

You don't see the whole picture if you look at the number unreviewed
patches alone (which is btw roughly as much as what you've committed
this year!). I for example, am very interested in getting some of the
simple things I've discovered fixed. Unfortunately the whole process
is so slow and uncertain at the moment I don't know if it's worth the
effort to send even more patches. (I'm optimistic though and currently
waiting for FSF papers to arrive.) I'm not claiming you're losing a
major contributor in me but you are losing someone who is (a) capable
of fixing things and (b) cares deeply about GNU Classpath.

Pekka

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley  wrote:
> I hereby offer to review some patches.  Please send pointers to the
> list.

http://developer.classpath.org/pipermail/classpath-patches/2010-November/006511.html

http://developer.classpath.org/pipermail/classpath-patches/2010-November/006513.html

http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html

There's also 10-15 patches from Ivan sitting in the archives and from
last count roughly the same amount of patches in Bugzilla.

Pekka

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley  wrote:
> Anyway, I don't mind that as long as someone else does it.  (Clearly,
> the issue of developers without commit access is a red herring, as
> every developer should have commit access.)

But it's not a red herring! I don't expect to have commit rights to
GNU Classpath. I'm more than happy to send patches to the list and
have someone else merge them (that's in fact a model I personally
prefer). Unfortunately, as things stand, CVS as itself is totally
useless for this model of development.

Pekka

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
 wrote:
>> For those who didn't see Pekka's blog on planet.classpath.org you can
>> find it here:
>> http://penberg.posterous.com/whats-the-future-of-gnu-classpath
>>
>> He makes some very good points. I agree with all of them.
>
> I agree on the general overtone.  Indeed, I already blogged about it:
>
> http://blog.fuseyism.com/index.php/2010/11/03/the-homogenisation-of-the-java-platform/
>
> There are several inaccuracies in the points themselves.  I'm not too
> surprised, given that Pekka is still new to the project, but I am surprised
> that you'd agree wholeheartedly with such little hesitation.

I hope my inaccuracies didn't get into the way of the overall point.

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
 wrote:
> Mauve has not been abandoned (as you acknowledge below).  You merely
> need to look at the logs to see that tests have been added e.g.
>
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/mauve/gnu/testlet/java/security/Policy/setPolicy.java?cvsroot=mauve
>
> I posted to the Mauve mailing list about this last week.  It is in the same
> state as GNU Classpath, in that there are very few contributors, but it has
> not been abandoned.

Sorry about that. It looked abandoned last time I checked it out but I
guess I wasn't looking hard enough.

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
 wrote:
> 1.6 work has already been done on GNU Classpath, though that is now
> some time back; it's all there in the mailing list archives though.

Last time I tested Jato with GNU Classpath, there were some obvious
missing 1.6 APIs in java.lang.Math, for example. I need to check if
that's changed now. The overall feel I get from GNU Classpath is that
it's quite firmly stuck at 1.5 level, though.

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
 wrote:
> There is no 1.7 API to implement yet, so that's a pointless statement.
> I also tend to still believe in the general Classpath spirit that we
> implement primarily to match the requirements of applications, not
> specific applications.  We have no hope of ever TCKing the thing
> anyway, and to my knowledge it's never been used with a JDK that's not
> Oracle-based so I have no trust in its reliability.

There's APIs that are likely to make it into 1.7 (e.g. NIO2). I don't
see much to be gained from not implementing them now. You might have a
different view on what should be implemented and what not but that
doesn't make my statement pointless.

>> Now the cool thing would be if I said "lets do them all right now!".
>> But instead I am going on vacation and be offline for about two weeks.
>> Sorry about that. But I didn't want to not respond at all.
>>
>> As soon as I am back I would like us to at least start moving to
>> mercurial on savannah if people don't mind.
>
> Yes, I do mind.
>
> We already discussed this some time back:
>
> http://developer.classpath.org/pipermail/classpath/2008-June/002629.html
>
> and nothing happened.  I don't particularly see any huge benefit to
> moving the repository to a different version control system.  It would
> make more sense if there were lots of contributors but there aren't.
> As is, if you're going to put some time in, I'd rather it was spent
> reviewing patches than messing about with the VCS.

Hey, it's not as if I'm making this up! This is a genuine experience
from someone who wanted to contribute a simple thing to GNU Classpath.
While *you* don't see the benefit from transitioning to Mercurial or
git, I certainly do, and I claim other people who are used to modern
tooling see that as well.

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
 wrote:
> One of Pekka's motivations is also flawed:
>
> 'how much problems it causes for developers that don't have commit
> rights to the centralized repository!'
>
> Moving it all to Mercurial just so it's easier for someone else to
> create a forked lower-quality copy that accepts unreviewed patches is
> not a good motivation IMHO.

I hope you don't mean this:

https://github.com/penberg/classpath

because it's (a) not a fork (it's queue of patches I want to feed to
mainline) and (b) I don't merge unreviewed patches (I reviewed them
myself).

> The discussion earlier today:
>
> http://developer.classpath.org/pipermail/classpath-patches/2010-December/006528.html
>
> shows exactly why we do need patch review and discussion.

Again, I have nothing against patch review and discussion. My other
point of patches needing more swift attention has nothing to do with
my point about modern tooling.

>> The discussion on the patches mailinglist does show a real problem
>> though. We have very little active hackers, and so aren't doing very
>> well helping new hackers like Pekka and Ivan to get their work
>> integrated.
>
> I agree this is a problem.  But whining about it won't help.  Getting
> involved would.  I'm doing my best but I can't do everything.  There
> are only so many hours in the day.  I'd prefe

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
 wrote:
>> As soon as I am back I would like us to at least start moving to
>> mercurial on savannah if people don't mind.
>
> Yes, I do mind.
>
> We already discussed this some time back:
>
> http://developer.classpath.org/pipermail/classpath/2008-June/002629.html
>
> and nothing happened.  I don't particularly see any huge benefit to
> moving the repository to a different version control system.  It would
> make more sense if there were lots of contributors but there aren't.
> As is, if you're going to put some time in, I'd rather it was spent
> reviewing patches than messing about with the VCS.
>
> One of Pekka's motivations is also flawed:
>
> 'how much problems it causes for developers that don't have commit
> rights to the centralized repository!'
>
> Moving it all to Mercurial just so it's easier for someone else to
> create a forked lower-quality copy that accepts unreviewed patches is
> not a good motivation IMHO.
>
> The discussion earlier today:
>
> http://developer.classpath.org/pipermail/classpath-patches/2010-December/006528.html
>
> shows exactly why we do need patch review and discussion.

No, no, that's not my motivation at all. Have you used Mercurial or
git? CVS make local *development* unnecessary hard. I'm not trying to
bypass the review process (which is a great thing!) with a tool. I
just find it utterly silly that I need to manually create a git mirror
of your CVS repository to make development experience sane.

Pekka

[ANNOUNCE] Jato v0.1.1 - a JIT-only virtual machine for Java

[Pekka Enberg]

 Hi all!

I'm proud to announce the release 0.1.1 of Jato!

Jato is an open source, JIT-only virtual machine for Java that aims to 
support

the JVM specification version 2 including 1.5 amendments. It is not complete
but you can run some Java applications with it on 32-bit x86 Linux machines.
Jato uses Boehm GC as its garbage collector and GNU Classpath to provide
essential Java run-time libraries. A port to the x86-64 architecture is
currently ongoing.

Highlights of this release:

   - Fixes to make Eclipse, Jython, Lusearch, and Xalan in DaCapo 
benchmarks to

 work (Tomek, Pekka)

   - Relaxed locking for monitors to improve performance (Tomek)

   - Fixes to the x86-64 port (Pekka)

   - Initial work to make Jato compile on Darwin (Pekka)

You can download the full source distribution here:

   http://www.kernel.org/pub/software/java/jato/jato-0.1.1.tar.bz2

or fetch the latest sources from the git repository:

   git clone git://git.kernel.org/pub/scm/java/jato/jato.git

If you have questions, comments, or suggestions, feel free to drop by at 
#jato

on irc.freenode.net or send an email to our mailing list at:

   http://groups.google.com/group/jatovm?hl=en

For more information, please check out the Jato home page at:

   http://www.jatovm.org/

 Pekka
---

Changes from v0.1.0 to v0.1.1:
--

Arthur HUILLET (1):
  lib/string: fix size computation and str_vprintf

Eduard - Gabriel Munteanu (2):
  vm: quit gracefully when there's nothing to load
  x86-64: fix call to fixup_vtable() from trampolines

Jim Huang (1):
  vm: Update URL to Java online documentation

Pekka Enberg (146):
  runtime: Implement Runtime.availableProcessors()
  runtime: Implement Runtime.freeMemory() and Runtime.totalMemory()
  torture: More DaCapo tests run now
  torture: Enable more DaCapo tests now that we're faster
  torture: Add JRuby to torture suite
  x86: Extract register number encoding to separate file
  x86: Move ModR/M and SIB encoding to encode.h
  x86: Move common atomic ops to atomic.h
  x86-64: Remove 'atomic_t' redefinition
  x86: Fix pointer cmpxchg() on 64-bit
  x86: Generic instruction encoding
  torture: Add script for comparing DaCapo JVM performance
  cafebabe: Remove 'pragma once' from header files
  vm: Remove unused variables from vm/thread.c
  boehmgc: Auto-detect when running under valgrind
  x86: Make called_from_jit_trampoline() more robust
  Merge branches 'boehmgc/valgrind' and 'x86/stackframe'
  vm: Fix PRELOAD_OPTIONAL handling
  vm: Fix Classpath 0.98 support
  Merge branch 'master' of g...@github.com:penberg/jato
  Revert "jit: fix vtable fixup"
  x86: Optimize fixup_direct_calls() locking
  x86: Convert INSN_RET to use generic instruction encode
  vm: Introduce a -Xnewgc command line option
  gc: Fix verbose GC handling in gc_alloc()
  x86: Remove volatile from atomic_t definition
  jit: Don't ensure class init if already compiled
  Makefile: Introduce 'tags' target
  Makefile: Fix 'tags' target to append to tags file
  vm: Make struct vm_object smaller
  torture: Enable dacapo xalan and lusearch tests
  torture: Improve dacapo comparison pretty-printing
  torture: Cleanup strach directory after each dacapo test
  torture: Clean up compare-dacapo script some more
  vm: Fix comparison between signed and unsigned
  torture: Fix compare-dacapo for xalan
  vm: Move ->array_length out of struct vm_object
  test: Fix object-stub.c compilation error
  vm: Fix up version number confusion
  Makefile: Remove references to JamVM
  x86-64: Fix REG_EAX references in instruction selector
  Makefile: Remove unused OS variable
  x86-64: Fix 32-bit cross compile on 64-bit
  runtime: Use GNU classpath VMSystem.nanoTime()
  runtime: Use switch statement instead of sparse array
  Revert "vm: fix condition in transform_method_for_call()"
  Revert "vm: implement CallNonvirtualXXXMethod() JNI function family"
  Revert "vm: implement mising requirement for CallXXXMethod() JNI 
function familiy"
  Revert "runtime: make vm_object_to_vm_method() work for 
java.lang.reflect.Constructor"

  x86: Convert some SSE instructions to use insn_encode
  torture: Enable 'eclipse' dacapo benchmark
  test: Fix 'make check'
  x86: Fix typo in encode.c
  x86: Convert more SSE instructions to use insn_encode()
  jit: Fail lazily for missing methods
  x86-64: Fix backtrace register names
  x86-64: Fix '-Xtrace:invoke' on 64-bit
  runtime: Use throw_oom_error()
  x86-64: Kill 64-bit emitter alias macros
  x86: Extract fixup code in a separate file
  x86-64: F

[ANNOUNCE] Jato v0.0.2 - a JIT-only virtual machine for Java

[Pekka Enberg]

Hi all!

I'm proud to announce the release 0.0.2 of Jato!

Jato is a JIT-only virtual machine for Java that can run some Java applications
under GNU/Linux on modern 32-bit x86 CPUs that support the SSE2 instruction
set. A port to the x86-64 machine architecture is currently being developed.
Jato depends on GNU Classpath to provide core Java runtime classes. The VM is
licensed under the GPLv2 with GNU Classpath linking exception.

You can download the full source distribution at at the following location:

  http://www.kernel.org/pub/software/java/jato/jato-0.0.2.tar.bz2

or fetch the latest sources from the git repository:

  git clone git://git.kernel.org/pub/scm/java/jato/jato.git

This release has bunch of fixes to make some new programs run under Jato:

  - Java Tris: http://bit.ly/7wrE4H

  - Clojure REPL: http://clojure.org/

  - DaCapo: http://www.dacapobench.org/

There's also lots of infrastructure work for garbage collection (not functional
yet) and fixes to the x86-64 port (also not fully functional).

If you have questions, comments, or suggestions, feel free to drop by at #jato
on irc.freenode.net or send an email to our mailing list at:

  http://groups.google.com/group/jatovm?hl=en
 
For more information, please refer to Jato home page at:

  http://www.jatovm.org/

Pekka
---

Changes from v0.0.1 to v0.0.2:
--

Arthur HUILLET (1):
  Added dependencies installation instructions for Arch Linux

Eduard - Gabriel Munteanu (16):
  vm: record type information in args_map
  x86-64: move received parameters to non-fixed registers
  x86-64: make EXPR_LOCAL use the non-fixed registers
  x86-64: don't propagate fixed register in EXPR_ARG_THIS
  x86-64: implement INSN_MOV_REG_MEMINDEX
  x86-64: handle %r13 properly in indirect calls
  x86-64: implement STMT_ARRAY_CHECK(array_check) properly
  x86-64: implement STMT_ARRAY_STORE_CHECK(reg, reg) properly
  x86-64: define all XMM registers
  x86-64: add XMM register encodings
  buffer: introduce buffer_append_str()
  x86-64: add long (multi-byte) opcode variant of __emit_reg_reg()
  x86-64: XMM args register assignment
  x86-64: emitter for XMM to XMM move
  x86-64: parse method arguments by accessing the linked-list
  x86-64: implement exception_check()

Pekka Enberg (86):
  Use gzip in scripts/make-release
  Add include/vm/version.h to .gitignore
  x86: Kill useless get_greg() wrapper
  x86: Register state saving
  x86-64: Register state saving
  gc: Pass register state to gc_start() and gc_safepoint()
  gc: Remove dead code
  Fix JAR file loading error message
  Bump up java.version to 1.6
  Implement Method.getModifiersInternal()
  vm: Sort natives table
  Implement AtomicLong.VMSupportsCS8()
  x86: Separate 32 and 64-bit atomic.h
  Implement Unsafe.compareAndSwapLong()
  regression: Move reflection API tests to new package
  Move LICENSE to top level
  jit: rename subroutines_should_not_occure() to fail_subroutine_bc()
  jit: Move reference to header of jit/subroutine.c
  jit: clean up includes in jit/subroutine.c
  Update README
  Fix typo in README
  x86: Fix instruction selector deadlock in invoke()
  mmix: Fix native call function signatures
  Move reflection.c and unsafe.c to runtime directory
  runtime: Extract stack walker implementation
  runtime: Move unsafe.h to include/runtime
  runtime: Move VM runtime implementation to runtime.c
  runtime: Move VM class implementation to class.c
  runtime: Implement Field.getLong()
  Move cafebabe to proper top-level directories
  x86: Cleanup emit-code.c
  runtime: Rename to_primitive_value() to to_jlong_value()
  x86: Use lookup table for register numbers
  x86-64: Use lookup table for register numbers
  x86: Unify __encode_reg() implementations
  x86: Unify x86 XMM register names
  x86: Unify general purpose register numbers
  x86: Fix register encoding function names
  x86: Mark object allocation points as safepoints
  x86: Make non-globally used function static
  x86: Introduce ->flags to struct insn
  x86: Shrink struct insn to 128 bytes
  x86: Use uint32_t for offsets and reoder struct members
  x86-64: Fix native_call() signature
  x86: Use 16 bits for bytecode offsets
  jit: Add ->flags member in struct live_interval
  vm: Fix preload error messages
  x86: Fix up SSE class field fixup problem
  Remove generated source file from the tree
  Fix BUILD_ARCH on OpenSolaris 10
  Add OpenSolaris 10 dependencies to README
  Fix gitignore file
  x86: Move fixup_static() next to fixup_static_at()
  x86: Fix fixup_static() for REX prefixed SSE instructions
  x86: Improve SSE instruction detection
  x86-64: Fix emit-code.c compilation
  ji

[ANNOUNCE] Jato v0.0.1 - a simple JIT-only virtual machine for Java

[Pekka Enberg]

Hi all,

I am proud to announce the release of Jato v0.0.1 "buy more RAM"-edition!

Jato is a JIT-only virtual machine for Java that can run some simple programs
under GNU/Linux on modern 32-bit x86 CPUs. A port to the x86-64 machine
architecture is currently being developed. Jato depends on GNU Classpath to
provide core Java runtime classes.

The VM is licensed under the GPLv2 with the GNU Classpath linking exception
which makes embedding Jato to third-party applications possible.

You can download version 0.0.1 here:

  http://www.kernel.org/pub/software/java/jato/jato-0.0.1.tar.bz2

For further details on git repository, issue tracker, mailing list, IRC
channel, and documentation, please check out our home page at:

  http://jatovm.sf.net/

Features of the VM:

  - Supports the full JVM instruction set on 32-bit x86 machines running under
GNU/Linux

  - Support for GNU Classpath 0.96

  - JIT-only execution

  - Linear scan register allocator

  - Support for profiling Java programs with the Performance Counters ("perf")
tool of Linux 2.6.31 and later

  - No JIT optimizations! ("Write tight code!")

  - No verifier! ("Don't run untrusted programs!")

  - No garbage collector! ("Buy more RAM!")

Applications which run under the VM:

  - System.out.println("hello, world")

  - Sun Microsystem's Hello World Swing

  - SciMark2
 
  - Not a whole lot more!

I would like to thank Jim Huang, Arthur Huillet, Saeed Siam, Vegard Nossum,
Tomek Grabiec, and Eduard-Gabriel Munteanu for making the release happen and
Google for letting us participate in Summer of Code 2008 and 2009!

If you're interested in helping out, the simplest way to get started is to try 
to
run your favorite Java applications and send us bug reports (or patches) at
jatovm-de...@lists.sourceforge.net or drop by at #jato on irc.freenode.net when
you see the VM crash and burn!

Pekka