On May 21, 2010, at 1:11 PM, Daniel D. Daugherty wrote: > 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.
There are existing asserts and I think they should just be converted to exceptions. We could also consider making the base table size into a flag so it could be increased. tom > > 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 >>> >> >> >> >
