On 08/17/2014 12:55 PM, Florian Weimer wrote:
On 08/16/2014 12:39 AM, John Rose wrote:
Do you have a use case in mind that could be expressed as a more
tightly focused API?
My use-case is run-time class generation and avoiding unnecessary
retention of classes which are referred to by the generated class.
I do not need constant pool patching. It would be interesting to
inject static final values of arbitrary types, but I could use a
thread-local variable for that if necessary. Being able to pass
parameters to <clinit> would be a much cleaner way to achieve that,
but it doesn't seem strictly necessary.
As john said, you can also use one classloader by class and then for the
static values either use a ClassValue or store them as field of the
classloader
(as I've done in the prototype)
> Or, most or all of dAC could be simulated using regular class
> loading, into a single-use ClassLoader object. The nominal bytecodes
> would have to be rewritten to use invokedynamic to manage the
> linking, at least to host-class names.
Why is that? Because you cannot directly reference to a class by name
if you don't use the class loader which was used to define the class
to look up the name?
An anonymous loaded class has a fulll access to the members of the host
class even if the members is declared private,
to simulate this all method and field instructions that access to that
host class are re-written to an invokedynamic
which at runtime will use a lookup object that can see the private
member of the host class instead of the lookup
object corresponding to the anonymous class which is pass as first
parameter of the bootstrap method.
lines 69 and 78 of the prototype,
https://gist.github.com/forax/0c25deac1867d1ef3247#file-gistfile1-java-L69,
rewrite the bytecode to use invokedynamic and line 180
https://gist.github.com/forax/0c25deac1867d1ef3247#file-gistfile1-java-L180
the bootstrap method which is called at runtime uses the lookup object
stored
in the classloader instead of the lookup object provided by the
invokedynamic mechanism
to access the methods and fields of the host class to trump the
classical accessibility checks of the JVM.
cheers,
Rémi
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
