Am 02.09.2014 16:38, schrieb Vladimir Ivanov:
[...]
It's possible to optimize some shapes of method handle chains (like
nested GWTs) and tailor special LambdaForm shape or do some inlining
during bytecode translation. Though such specialization contradicts LF
sharing goal, probable benefits may worth the effort.
Maybe something to investigate after LF sharing.
[...]
I don't think it will work. If you load a MethodHandle from
WeakReference and then use MH.invoke*, inlining will be broken for sure.
right, I forgot that I have to invoke it then. And things like
foldArguments or exactInvoker won't help.
For example if I do
def foo(x) {
x.bar()
}
Then after the first execution the class this has defined will prevent
the class used for x to unload. In case of a virtual method I may get
away with a parent or interface if I adapt my receiver runtime class
check to use WeakReferences. But other parts of the handle will keep the
class in memory. And that for as long as the class containing foo(x)
exists, even if it is never touched again. In a system that creates
often classes from scripts this could turn into a problem.
[...]
since in the traditional implementation the callsite is always Object[]
based we have one such class per executed target method. Of course we
run into profile pollution if we use the same callsite object for
multiple callsites, but it would be the same for the target method, so
in my thinking there is no real problem. Anyway... if there is no need
to create such a class per target of a direct method handle, then I
would expect quite a lot of less memory usage from your approach
That's interesting. I'll try to experiment with that. Thanks for sharing
your experience.
always happy if I can contribute something interesting in the end
bye Jochen
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
