On 03.06.2016 22:20, Alex Buckley wrote: [...]
Why don't you believe it? The "Under The Hood" presentation shows that layer creation makes the JVM aware of modules and their relationships.
because I was thinking it will lower performance. Sure, benchmarks are often driven by code of callsites, that are actually no moving much, and in such benchmarks there will be no problem. And yes, this checkc has to be done only once, unless the callsite has to be reevaluated... Still it will increase the one time cost, unless you meet one of those callsites, that require the JVM to regularly deopt. But on the other hand the JVM is not good at recovering from a deopt anyway (at least that is my perception)... so maybe it does not really matter in the end.
Later, when the JVM resolves the descriptor of an invokevirtual instruction, it checks that the current class (containing invokevirtual) can access the class referenced in the descriptor, and this check takes module membership, exports, and readability into account. Can the current class's module read the target class's module, and does the target class's module export the target class to (at least) the current class's module?
I see.. and I assume that counts for get/setField and all invoke instructions including invokeSpecial and newinstance.
There's a clear contrast between the two-way check performed by the JVM, and the one-way check (exports only, readability "for free") performed by Core Reflection.
so... odes reflection code still produce runtime helper classes for invocation? That is then a dynamic module based solution?
bye Jochen
