This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: JNI Performance

From: Bryce McKinlay <bryce at mckinlay dot net dot nz>
To: tromey at redhat dot com
Cc: Java <java at gcc dot gnu dot org>
Date: Mon, 10 Nov 2003 13:35:41 +1300
Subject: Re: JNI Performance
References: <482B279A-0759-11D8-BB2F-003065F97F7C@mckinlay.net.nz> <16285.42929.469047.16124@creche.redhat.com> <544ED8A4-118F-11D8-88E8-003065F97F7C@mckinlay.net.nz> <87smkxaxq1.fsf@fleche.redhat.com>

On Nov 10, 2003, at 1:11 PM, Tom Tromey wrote:

There is a sort of open question about binary compatibility and
low-level calls.  Our JNI stubs make direct calls into libgcj.  So
does java code, e.g. we generate direct calls to _Jv_Throw.

Well, I don't see any problem with that as far as binary compatibility is concerned. Things like _Jv_Throw have well-defined semantics, and as the maintainers of the runtime, we are in a good position to make sure that they don't change in incompatible ways. After all, things like glibc use the C ABI as well and don't seem to have much problem maintaining binary compatibility (in general) between releases).

You could argue that the C ABI's symbol lookups and PLT indirections are a performance penalty, but operating systems seem to be moving towards prelinking/prebinding models to prevent this. So I'm pretty happy with the way we do it now.

Regards

Bryce.

Follow-Ups:
- Re: JNI Performance
  - From: Tom Tromey

References:
- Re: JNI Performance
  - From: Bryce McKinlay
- Re: JNI Performance
  - From: Tom Tromey

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