Hello.
Just a few notes about class collecting and re-loading.
I think - it's a bad idea to gc classes, in general.
But unneded classes eats memory, and one may wish to
reload another class with the same name and interface
instead of old one.
Right. Why not, then, aim this goal?
I.e. class is not fully unloaded, only bytecode, attributes,
most of constants. Just vital interface part is to remain -
methods and fields named and signatures.
If the class will be re-loaded - JVM just need to ensure,
that methods has the same jmethod_id and fields has the same
jfield_id.
This may greatly simplify the life of JNI writers, and,
JIT authors :-)
John Keiser wrote:
>
> OK, it's been a bit, and I've been doing some heavy thinking about
> jnilink. There is a huge amount of improvement which can be made, in terms
> of speed, readability and ease-of-use. I believe I have finally cut it down
> to its core components.
> The main point of jnilink is to ensure that the class you want is
> available when you want it and remains available during the execution of the
> native method. Anything else is unnecessary. Methods and fields are all
> corollaries to that one objective: if the class goes invalid, so do methods
> and fields; and if it does not, they do not. Thus I am adding the
> requirement that every time you enter a native method, you call
> LINK_LinkClass() in order to make sure the class is linked. This will
> ensure that you have, at the very least, a local reference to the class
> which will be valid until the end of the function (when 1.2 comes around, I
> will create new local references to the weakly-referred-to class).
--
Maxim Kizub, Forestro
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Visit Kiev language homepage http://forestro.com/kiev/
