On 03/08/2015 12:56 AM, Peter Levart wrote:

On 03/07/2015 02:53 PM, Remi Forax wrote:

On 03/07/2015 06:31 AM, John Rose wrote:

(I wish we had a similar candidate for invokespecial/super. That is badly twisted around the verifier.)

One way to solve the problem is to consider that invokedynamic <init> is a special 'bytecode' for the verifier and that the verifier will allow to call it on an non-initialized reference and
consider the reference as been initialized after that.


As I understand the problem is security-related. By mandating that each constructor chains to a super constructor (or one of sibling constructors that finally calls super), a class can rely on the fact that it's state is initialized using one of accessible constructors. The verifier makes sure there can be no subclass that doesn't call one of super constructors as part of object construction. Some security-related idioms are based on that guarantee. For example: services looked-up using ServiceLoader typically use an abstract class as the service "interface" that implementations must extend. The abstract class constructor checks for permissions. Each service implementation subclass must call the super constructor and the permission check in it has the subclass code on the call-stack when making a permission check.

So how can verifier be sure that "invokedynamic <super-init>" eventually invokes one of the super constructors?

Yes, right, I was expected something like this.

You need to restrict the set of method handles that are allowed to be installed inside a CallSite corresponding to such kind of invokedynamic. Something like: you can do any transformations you want on the arguments but not on the receiver (no drop, no permute, no filter) and then you need to call unconditionally a method handle created using findSpecial on the super class.



mlvm-dev mailing list

Reply via email to