Re: [cp-patches] [generics] RFC : implementation of jjava.lang.instrument package

[Mark Wielaard]

Hi Nicolas,

On Sat, 2005-11-26 at 19:11 +0100, Nicolas Geoffray wrote:
> >Yes, that name is OK. I don't know how much we can actually share
> >between runtimes though. The interface is pretty minimal already, so a
> >split between VMInstrumentationImpl and InstrumentationImpl that calls
> >the VM class seems overkill.
> >
> The InstrumentationImpl.getObjectSize is clearly a native for vm.
> And we also need a native redefineClass(Class, byte[]).
> 
> If we don't provide a VMInstrumentationImpl class, would
> these method be native in InstrumentationImpl? (I thought
> vm implementors only had to care about vm/reference/* files?)

Ideally yes. I was just thinking that if the interface between
InstrumentationImpl and VMInstrumentationImpl is really thin and there
is not much code that can be shared maybe we just have one class that
the VM should implement. I haven't thought very deep about the actual
implementation yet or how easy it is to write generic code that can be
easily shared.

> Because it's the vm that parses arguments, it knowns if the
> application does instrumentation. Therefore, if it supports
> redefining classes, it can set a flag or change definition of
> VMClassLoader.defineClass. The vm then creates an
> InstrumentationImpl object and calls premain.
> 
> The VMClassLoader.defineClass will be changed to call a
> private InstrumentationImpl.defineClass method. This method will then call
> each transformer.
> 
> Does that sound correct to you? This way I don't modify 
> ClassLoader.defineClass.

Yes, this makes perfect sense.

Thanks,

Mark