Hi,
Design of MethodType have problems:
1, the immutable have more execution time.
2, It will prevent loader from gc-ing.
why?
1, in methodType(*) creation methods, every temp rubbish MethodType
immutable will take more time, There must have more people know more
about it.
There need a true factory for MethodType,
In my implementation, it will be:
MTFactory extends ArrayList<Class>{ Class rtype;
hashCode(){}
equals(){}
methodType(*){
rtype=returnType, addAll(types);
result=internTable.get(this);
if(result!=null) return result;
...
}
}
And the factory far away the global singleton, so the point 2 not
problem any more.
As to how to hold your MTFactory, it's your biz, OK?
BTW:
1, JVMS7 StackMapTable attribute chapter say: it's can be ignore even
if >=java7.
But in 4.10.1 say like this : must verify the stack frame map, if
not, error reported.
So who is the stupid PM?
2, Lamda is just a tool, If the tool changed to the target, the nature
of tool is lose!
3, can you redesign the BootstrapMethods? it's just a CallSiteFactory. KISS.
Since it's a factory, so there are rich factory pattern and factory
method implementations.
Why not limit it static or new style? In nature the new is static of Class.
My advice, when redesign, clear the concepts:
MethodHandle just a invoke* instruction.
MethodType is just FunctionType. dont just for OO so OO.
BootstrapMethod is right the CallSiteFactory, it's nothing.
So if it factorized, the static limitation will removed.
4, Again, I hope JDK team not follow the way of MSh.
Many people must admit, there are some guys in Msh really smarter than
most people(include myself). But what about the thing? Msh just not
let the thing worse, but never have capability to make thing better.
so even if genius, so what?
And chinan say: The smarter will kill yourself.
And I known, some one in the lists not like me. Not a matter. The
idiot think of all as idiot. That make it funny.
OK, If wrong, pls correct me if you will. I will happy to say thanks.
Best,
Qinxian
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
