Sorry that I'm really late to this e-mail thread. We don't support
using the RedefineClasses() API to add a public method. This testing
assertion is verified by an internal test (redefclass020) and I just
verified that the test does pass.
In Guillaume's scenarios, the Object.class bits are being replaced at
ClassFileLoadHook time or by providing the modified Object class using
the -Xbootclasspath/p parameter. (That info was provided in another
e-mail.) In neither of those cases is the RedefineClasses() API being
called so the error check I mention above isn't being made.
It more be worth adding a sanity check of some sort to the early
bring up/boot strapping logic to verify that the Object class that
we're about to load has the expected number of virtual methods. This
will allow us to get a cleaner error message for now.
Dan
On 4/28/2010 12:09 PM, Tom Rodriguez wrote:
I didn't think we supporting redefining Object and adding public methods after
JVM bootstrap. Adding methods to classes which are already loaded with
subclasses means that you have to generate new vtables for all subclasses and
as far as I know we don't do that. You might get more answer over on
serviceability-dev.
tom
On Apr 24, 2010, at 1:30 PM, Guillaume Pothier wrote:
Hi,
First of all I hope it is appropriate to ask this kind of question in
this list, otherwise what would be the correct forum?
Here is my problem: I'm adding public, non-native methods to the
Object class through instrumentation, and it seems that adding more
than 2 such methods causes the JVM to crash. I get different kinds of
crashes depending on the number of methods I add. With 3 and 4 methods
I get a SIGSEGV; with more methods I get an NPE during VM
initialization (in String.charAt). For testing purposes, all added
methods take no arguments and return void, and have an empty body
(only the RETURN bytecode).
Is that expected behavior? Is there something I can do about it?
Kind regards,
Guillaume Pothier
PhD student, University of Chile
