public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Fisher <pnfisher@redhat.com>
To: java-discuss@sourceware.cygnus.com
Cc: classpath@gnu.org
Subject: Proposal for CNI/JNI problems
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <y68k8lg6t70.fsf@ignucius.devel.redhat.com> (raw)

I've been working on coming up with an "acceptable" solution for
dealing with our current merger problems regarding the use of CNI and
JNI.  While it's important that Classpath continue to support JNI, CNI
does have significant benefits, and I'd like to start porting
Classpath to CNI, assuming we can get some sort of sane API mapping
worked out.

In the ideal world, I'd like to be able to write a Java class, mark
appropriate native methods, and then write CNI code.  gcjh would be
able to generate appropriate wrapper code that would translate CNI
calls into JNI calls at runtime.

The process seems to be rather straightforward, with the exception of
accessing fields.  The only fool proof method (that I know of) to
solve the problem is to trap reads and writes to a section of memory
set aside for fields when using JNI.  This would be unacceptably slow.
So I've written a bit of C++ which tries to turn the transparent
access of fields in CNI into something that the compiler can insert
appropriate JNI calls when needed.

Assuming we follow a few rules, we can treat fields as being
"mostly-transparent" and clue the compiler into inserting JNI calls at
appropriate locations.

Where transparency fails:
1) sizeof (field) != sizeof (basic data type)
2) reading/writing directly to the field must occur after the field
   has been "accessed"
3) fields are LocalRefs

Entering a C method when using JNI, would bundle up all the Java
fields into JNIField<type> objects stored in a CNI-like looking
structure.  So a jint field, would turn into a JNIField<jint> field.
JNIFields contain an automatic typecast for their appropriate basic
data type, such that in most cases, the object can be treated as
though it were a basic data type.  Any C++ operators that contain side
effects are overloaded.  JNIFields do not hold the value stored in the
equivalent Java field, until the JNIField is accessed through either
the automatic typecast or one of the overloaded operators.  For any
reading and writing that occurs w.r.t the address of the JNIField
directly, the JNIField destructor compares the initial field value
with the field value held when the current scope exits.

For cases where this transparency isn't good enough (I doubt this
would happen often), we can always just #ifdef out CNI and JNI
versions of a native function.

Assuming these losses are acceptable, I'll continue on with this
project.  Thoughts?

Here's a brief look at the current C++ class that I'm experimenting
with for the basic JNIField:

template<class T>
class JNIField
{
  T val, old_val;

  JNIEnv *env;
  jobject obj;
  jfieldID id;
  char *clazz, *field, *sig;

public:
  JNIField<T> (JNIEnv *env, jobject obj, 
	       char *clazz, char *field, char *sig);
  ~JNIField ();

  operator T();

  JNIField<T>& operator = (const T);
  JNIField<T>& operator += (const T);
  JNIField<T>& operator -= (const T);
  JNIField<T>& operator *= (const T);
  JNIField<T>& operator /= (const T);
  
  JNIField<T>& operator %= (const T);
  JNIField<T>& operator ^= (const T);
  JNIField<T>& operator &= (const T);
  JNIField<T>& operator |= (const T);
  JNIField<T>& operator >>= (const T);
  JNIField<T>& operator <<= (const T);

  const JNIField<T>& operator++ ();
  const JNIField<T>  operator++ (int);
  const JNIField<T>& operator-- ();
  const JNIField<T>  operator-- (int);

  void resolve_field ();
  void set_field (T new_val);
  T get_field ();
};

             reply	other threads:[~2000-04-01  0:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-01  0:00 Paul Fisher [this message]
2000-04-01  0:00 ` Per Bothner
2000-04-01  0:00   ` Paul Fisher
2000-04-01  0:00     ` Aaron M. Renn
2000-04-01  0:00       ` Stuart Ballard
2000-04-01  0:00         ` Chris Blizzard
2000-04-01  0:00           ` Chris Blizzard
2000-04-01  0:00     ` Per Bothner
2000-04-01  0:00   ` Jochen Hoenicke
2000-04-01  0:00     ` Per Bothner
2000-04-01  0:00     ` Stuart Ballard
2000-04-01  0:00     ` Jon Olson
2000-04-01  0:00   ` Bernd Kreimeier
2000-04-01  0:00     ` Per Bothner
2000-04-01  0:00       ` Bernd Kreimeier
2000-04-01  0:00         ` Per Bothner
2000-04-01  0:00           ` Bernd Kreimeier
2000-04-01  0:00             ` Per Bothner
2000-04-01  0:00               ` Bernd Kreimeier
2000-04-01  0:00                 ` Per Bothner
2000-04-01  0:00                   ` Alexandre Oliva
2000-04-01  0:00                   ` Bernd Kreimeier
  -- strict thread matches above, loose matches on Subject: below --
2000-04-01  0:00 Lam.Mark
2000-04-01  0:00 ` Aaron M. Renn
2000-04-01  0:00   ` Brian Jones
2000-04-01  0:00 David Pettersson
2000-04-01  0:00 ` Per Bothner
2000-04-01  0:00 Boehm, Hans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=y68k8lg6t70.fsf@ignucius.devel.redhat.com \
    --to=pnfisher@redhat.com \
    --cc=classpath@gnu.org \
    --cc=java-discuss@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).