[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[m2m-dev] Re: [ATL] Adding operation to ATL VM
|
Ah, ok. Then it depends on whether you can add to your meta-model.
Native operations on EClasses are already supported: operations are
declared in Ecore models and implemented in the generated code.
Performance impact: EMF operations are invoked through Java reflection.
If you cannot extend your meta-model's EClasses, using your own model
handler is indeed the best solution. The ASMModelElement subclass for
each model handler (e.g. ASMEMFModelElement for EMF model handler) will
handle all method invocations. You can add code to your own
ASMModelElement subclass to handle special operations, without affecting
the ATL VM code.
Regards,
Dennis
Mikaël Barbero schreef:
From my point of view, i understood that Eric wanted to add native
operations (i.e. direct call to java method).
I don't see any point against this idea. You'll probably better have to
create your own model handler with your own methods rather than changing
one of the already existing ones (but you can inherit from it).
As those method are statically registered, it should not have a big
impact on the VM performance (maybe on the class loading time).
Regards,
Mikael
Dennis Wagelaar wrote:
Hmm, perhaps this kind of information is better posted on the
development mailing list: m2m-dev@xxxxxxxxxxx
I'll add it in CC...
Eric MAES schreef:
Are there some limitations adding operations to the ATL VM ?
What are the consequences of addind a huge amount of operations ?
I'd like to add about thousand simple operations to the ATL VM. Does
anyone has tried such an experience and can tell me about his feeling
on ATL's possibilities and behavior ?
Thanks,
Regards
I assume you mean adding VM instructions? I found that the biggest
performance factor in the standard ATL VM is the creation of
stackframes with every method invocation. Interpreting instructions
only plays a small part.
Of course, there are currently only 22 instructions, which are
interpreted through a big if-then statement inside a while loop in the
ASMOperation class. I'm afraid that this solution does not scale up to
1000 instructions.
You may try to refactor the current approach to a more object-oriented
approach with an interpreter pattern. You can extend the
ASMInstruction and ASMInstructionWithOperand classes with new
subclasses for each instruction (in their own "instr" package, probably).
The behaviour for each instruction can be implemented in the
instruction class itself and ASMOperation only needs to call
instr.exec(frame). Instruction parsing is then done only once when the
asm file is loaded. ASMInstruction objects are created by the
ASMEmitter class. Probably a good idea to add an ASMInstructionFactory
class that creates the correct object for each mnemonic.
This may be a lot of work, but you probably need to do this if you
don't want the runtime transformation performance to become worse.
Regards,
Dennis
