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.
Rémi
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.
Peter
Rémi
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
