javadocAll callback definitions must derive from this interface. Any derived interfaces must define a callback method. You are responsible for deregistering your callback (if necessary) in its java.lang.Object.finalize() method. If native code attempts to call a callback which has been GC'd, you will likely crash the VM. If there is no method to deregister the callback (e.g. atexit in the C library), you must ensure that you always keep a live reference to the callback object.

A callback should generally never throw an exception, since it doesn't necessarily have an encompassing Java environment to catch it.

так что да, GC может финализировать объект, реализующий колбек. Чтобы GC не собирало объекты этот класс, можно прописать в CDS :)

P.S. Так что есть две методы:
- нотифицировать ссылающихся на колбек в finalize() методе
- прописать в CDS конкретные классы (что не хорошо в общем случае)

Blazkowicz,

Виноват, можно только смапить в read-область permgen только инстансы классов, а не сами классы.

Да, невнимательно прочел. Я сомневаюсь, что GC как-то "перемещает указатели"

авторPinned and dosed objects are the immovable objects on the Java heap. GC does not move these objects during compaction. These are the major cause of heap fragmentation.
All objects that are referenced from JNI are pinned. All objects on the heap that are referenced from the thread stacks are dosed.