BZ #83: global references broken

Status fields:

We have not implemented global references handling correctly, again.  I'll try to fix it
for the cacao-1.0.x branch and will rewrite the whole thing for the default branch.

This is the preliminary fix:

http://mips.complang.tuwien.ac.at/hg/cacao/rev/93decefa1711

and was shipped in the new releases.

I am taking over this one. It will be fixed in the handles branch. Global references are
used throughout our native code in this branch, so they need to be reworked anyways.

My first plan was to use the same implementation for our internal globalrefs and for JNI
globalrefs. This way we would reduce code duplication. My only concern is that malicious
JNI functions could then delete globalrefs held by the VM. That is the reason why we
might need two separate implementations after all. Below is a simple (mis)use case
scenario which would lead to that problem:

1) VM create globalref for A - refcount is 1
2) JNI-code creates globalref for A - refcount is 2 (JNI now has same globalref)
3) JNI-code deletes globalref for A - refcount is 1 (JNI has done a good job)
4) JNI-code deletes globalref for A - refcount is 0 (This should not be allowed)
5) GC collects A (This is bad!)

Any comments? Since I want to open a discussion here, I added the mailinglist to CC for
this bug.

As a reference: http://java.sun.com/docs/books/jni/html/refs.html

Decrementing a refcount too often is arguably a bug in the JNI code, and because JNI
code can do anything anyway, I would not care what happens then. Or does the spec say
anything about this?

I commited the new global reference implementation. As you can see it is still on the
handles branch, so I will leave this report open until the branch is merged back. This
is the changeset:

http://mips.complang.tuwien.ac.at/hg/cacao/rev/871aea8a6bb4

The handle branch is merged now. Is this still an issue? Is --enable-handles required in
order to profit from this fix?

Doesn't seem to be a problem.