The Great Startup Problem

[Jochen Theodorou]

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