[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: JavaHL unneccessary JNI method calls?

From: Patrick Mayweg <mayweg_at_qint.de>
Date: 2007-04-20 06:34:01 CEST

Hi Mark,
thank you I am well, just busy with my normal work.
I am still on the subversion mailing lists and think JavaHL is in good

You can do the optimizations, as long as you keep in mind to do them
only for the methods which return directly. In other JNI projects I did,
I learned that the hard way. Testing on small test set always work fine,
but when tried I on the real data, everything broke.

A good idea would be to use -verbose:jni -Xcheck:jni as JVM switches
during testing. with them java tells you a lot about everything you
might do wrong.


Mark Phippard wrote:
> On 4/19/07, Patrick Mayweg <mayweg@qint.de> wrote:
>> Hi Blair,
>> the reason for all this calls is that the number of local references is
>> limited to about 30 or 60. If you do not release them in cases where you
>> do not return directly to the JVM, you will see exceptions.
>> That is why I always deleted all local reference, as soon as possible.
> Patrick,
> First off, great to hear from you. I hope you are well.
> As I try to interpret what you are saying, I read it that this is
> somewhat theoretical. You were aware of limitations in the number of
> local refs so you made it a policy to clean them up. However, given
> that we do not create that many during a method call, and the methods
> always return to the JVM which should then clean them up
> automatically, aren't Blair's optimizations valid to make to the code?

Qint Software GmbH
Fichtenstr. 19
82110 Germering
+49 89 89026748
Sitz: München HRB 117326
Geschäftsführer: Hans Marggraff, Patrick Mayweg
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 20 06:34:11 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.