John Rose a écrit : > On Apr 19, 2008, at 12:09 PM, Rémi Forax wrote: > >> Hi all, >> there are several changes, i would like to apply on >> AnonymousClassLoader: >> - make a clean separation between the classloader, the constant pool >> parser and >> the patch array. >> - avoid to iterate over all constant pool entries when applying a patch >> on the same base class (remove indexOf() in makePatchArray) >> - try to make it thread safe >> - allocate the bytecode array using ByteBuffer instead of byte[] >> (not sure it's possible). >> - generify it (Class => Class<?>) > > Those are all good moves on the road from demo to product... Thanks.
The source code is available here: http://www-igm.univ-mlv.fr/~forax/tmp/davinci-anonk.zip I've sent a previous message monday to the mlvm list but it seems it was rejected because its size was too large (codes as attachment). So i re-sent it now with a link. The zip contains: - AnonymousClassLoader: load class (or a patch) as inner-class of a host class. - ClassPatch: a class and its patch array, it is created from a ConstantPoolParser - ConstantPoolParser: parse the constant pool, call a visitor for each entry - ConstantPoolVisitor: called by the parser, can modified a patch using of of it's method put*. AnonymousTest is a test Why a visitor ? it avoid to reify the constant pool, i.e to create one object by entry, this approach is not new, ASM use a similar trick. After hesitation, i've decided to surface constant pool index instead of using opaque handle, so at Java level, it's possible to try to change a constant pool entry by an incompatible one. ClassPatch is now the only class that is mutable, the other are non mutable. I'm not a native english speaker, so doc comments are written in common (+french) english, it will cool if someone can fix them :) > > When working with the CP parser, consider that we'll be wanting a > Java-only emulation of the loader. For that we'll need to edit class > files as well as read them. Note that ldc of non-string object will > require bytecode editing, not just CP editing. Forward compatibility is cool but i'm not sure emulating an AnonymousClassLoader is a good idea. I think it's not up to language implementors to simuate their features because they see the big picture. Furthermore, bytecode editing is in my opinion too hard to not use library like ASM or BCEL. BTW, i now understand why you want MethodHandle to be impelemented by plain Java class. > > (Bytecode editing of extended invoke sites might also be a plausible > way to manage extensions like method handles... But it's probably > easier to tell the language backend to sniff the JVM version and alter > its code generation in the first place. Except for a few cases like > static bytecode compilation.) yes > > -- John > Rémi _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
