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
Hi Mark,
Mark Wielaard wrote:
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 t
Hi Nicolas,
On Mon, 2005-11-28 at 19:08 +0100, Nicolas Geoffray wrote:
> Here's two files, InstrumentationImpl and VMInstrumentationImpl.
> I put all native vm specific methods in VMInstrumentationImpl, but
> if you think it's not necessary, it's ok with me to have all these methods
> in Instrumen
Hi Mark
Mark Wielaard wrote:
Hi Nicolas,
On Mon, 2005-11-28 at 19:08 +0100, Nicolas Geoffray wrote:
Here's two files, InstrumentationImpl and VMInstrumentationImpl.
I put all native vm specific methods in VMInstrumentationImpl, but
if you think it's not necessary, it's ok with me to have a
Hi Nicolas,
On Thu, 2005-12-01 at 17:51 +0100, Nicolas Geoffray wrote:
> >Also if something went wrong with the transformation
> >of any of them we might want to have a cancelRedefineClass() to let
> the
> >VM know we won't be applying any prepared classes.
> >
> I had in mind that the VM wouldn't
Hi Mark,
Mark Wielaard wrote:
My idea was even that a VM might only want to have one redefine
prepare/apply cycle running at the same time. Then it can easily cleanup
anything not used. But this might be optimizing for an unusual case. We
can probably assume that transformers will actually tra
Hi Nicolas,
On Fri, 2005-12-02 at 12:22 +0100, Nicolas Geoffray wrote:
> >Aha. Sorry I missed the dual nature of the
> >ClassFileTransFormer.transform() method. I see you documented this in
> >your original patch. In that case I really do think we should move these
> >to vm/reference/java/lang and
Mark Wielaard wrote:
Yes, but it makes it easier to share code with ClassLoader and
VMClassLoader if we do this. Then callTransformers doesn't have to be
public, but can just be package private. Then we don't have to worry
about whether or not someone can get insecure access to a
IntrumentationI
On Fri, 2005-12-02 at 12:22 +0100, Nicolas Geoffray wrote:
> gnu/java/lang/instrument. Would you like InstrumentationImpl
> to be in vm/reference/java/lang/InsutrumentationImpl? This sounds
> weird. We could also make the callTransformers method public.
I think it's very helpful for vm implementor
Hi Nicolas,
On Fri, 2005-12-02 at 17:52 +0100, Nicolas Geoffray wrote:
> Last RFC, and I'm commiting this in
>
> 2005-12-02 Nicolas Geoffray <[EMAIL PROTECTED]>
>
> * java/lang/instrument: New directory.
> * java/lang/instrument/ClassDefinition.java:
> New file.
> * java/lang/
Hi Christian,
Christian Thalinger wrote:
On Fri, 2005-12-02 at 12:22 +0100, Nicolas Geoffray wrote:
gnu/java/lang/instrument. Would you like InstrumentationImpl
to be in vm/reference/java/lang/InsutrumentationImpl? This sounds
weird. We could also make the callTransformers method public.
11 matches
Mail list logo
