Re: [Sablevm-developer] Incrasing SVM_FRAME_NATIVE_REFS_MIN

[Grzegorz B. P. <ga...@de...>]

W li=B6cie z =B6ro, 03-03-2004, godz. 20:09, Etienne Gagnon pisze:=20
> This minimum is encoded in the JNI specification.  You may petition Sun=
 to
> increase it, or alternatively, you could implement the related JNI
> calls that allows native code to ask for more native references
> *explicitly*.
It'd be nice to have them. I'll return to that in a second.

I haven't had much time to write this email, but before writing I took
a look at http://java.sun.com/docs/books/jni/html/refs.html, now I have
time to actually put here these snippets:

"In most cases, you do not have to worry about freeing local references
 when implementing a native method. The Java virtual machine frees them
 for you when the native method returns to the caller."
(honestly, I think it's bad introduction :-/ it encourages not to care.
It explains why we'll find tons of such programs that "don't care".)

"The JNI specification dictates that the virtual machine automatically
 ensures that each native method can create AT LEAST 16 local
 references." [*]

"If, however, there is a need to create additional local references, a
 native method MAY issue an EnsureLocalCapacity call to make sure that
 space for a sufficient number of local references is available." [*]

"The native code MAY create local references beyond the default
 capacity of 16 or the capacity reserved in a PushLocalFrame or
 EnsureLocalCapacity call. The virtual machine implementation WILL TRY
 to allocate the memory needed for the local reference. There is no
 guarantee, however, that memory will be available." [*]

So, I think Jonny programmer reads it as: "Sun's JVM will allocate
additional references as you use them. Don't worry."

Therefor I believe that allowing for usage of additional references
_without_ calling EnsureLocalCapacity is still in line w/ specs!
(Whether it's good idea to depend on implementation-specific and not
guaranteed behavior is another story, and I believe we fully agree on
how harmful it is.)

> I do NOT think that changing SableVM in order to support BROKEN JNI cod=
e
> is the right thing to do.  Instead, SableVM could be made more helpful =
to
> the broken code developer by giving him a better error message, includi=
ng
> a stack trace and an explicit message telling him about the need to eit=
her
> free unused local references (in a loop, for example), or to request ex=
plicitly
> more local references.
For _today_ I am inclined take the pragmatic approach.

_IF_ SableVM supported EnsureLocalCapacity, I could probably somehow call
it internally, when the basic, 16-references limit is exceeded. It would
be fully within the freedom that specs leave. BUT it doesn't have this
functionality implemented, so the only way is to define something bigger
at compile time. I don't mean putting that change in "upstream" SableVM,
but for Debian, where current usability of SableVM is the primary objecti=
ve,
I'll do it, especially if the risk of breaking things is low.

I share your pain because of that, but I think it's the right thing to do=
 ATM.

Thanks and cheers,

					Grzegorz B. Prokopski

[*] The emphasises are mine.

PS: On the other hand there'd be (almost) nothing bad to print a warning
on stderr, when a native thread exceeds the number of references it has
guaranteed according to the specs (and I'd say that at the return of
such function it should be printed/noted how many references it actually
needed). Sun's JVM has already an option to do this: -verbose:jni.

--=20
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM