> Remain class pointer of classes Integer, LargePositive/NegativeInteger
> constant after recompiling these classes (for changing and adding some
> methods)?

It should.  Oops are oops.  A pointer to a class object, which pointer is residing in the Object memory model, will not be invalidated by changes to the content of that class object.

> Need to know this for install instruction of a LargeIntegers
> (arithmetics) plugin.

Watch out!  Oops are oops.  A pointer to a class stored outside the Object memory model will NOT be updated during garbage collection.  Accordingly, if you store it in a global between primitive calls, if you store it in a local during a primitive call with a call that can invoke GC, you must PRESUME the GC has invalidated the pointer!  Accordingly, you must provide facilities to assure that the oop is remapped (either by reloading it from the parameter stack, or by popping it from a the remappable object stack).

(I always wondered why the interpreterProxy doesn't provide direct access to the special objects array, which would be another useful place to safely store remappable information.  In another posting, I proposed an unworkable solution of storing an oop in a global during a class initialization (which chokes on the likely GC between primitive calls).  If the oop could be stored in the special objects array, and the index thereto could be stored in the global, this functionality could be accomplished.)