RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

[Peter Levart]

On 11/27/2013 08:40 AM, David Holmes wrote:
>
>
> On 27/11/2013 2:16 AM, David Chase wrote:
>>
>> On 2013-11-26, at 8:12 AM, David Chase <david.r.chase at oracle.com> wrote:
>>> On 2013-11-26, at 7:32 AM, David Holmes <david.holmes at oracle.com> 
>>> wrote:
>>>> On 26/11/2013 10:16 PM, David Chase wrote:
>>>>>
>>>>> On 2013-11-26, at 7:12 AM, David Holmes <david.holmes at oracle.com> 
>>>>> wrote:
>>>>>> On 26/11/2013 9:56 PM, David Chase wrote:
>>>>>>>
>>>>>>> On 2013-11-25, at 9:18 PM, David Holmes 
>>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>>> We do have the jdk.internal namespace. But I think Unsafe is as 
>>>>>>>> good a place as any - though maybe sun.misc.VM is marginally 
>>>>>>>> better?
>>>>>>>
>>>>>>> Does anyone have any problems with sun.misc.VM as a choice?
>>>>>>> I have to do a minor revision to the hotspot commit anyway.
>>>>>>> Is sun.misc.VM also loaded very early anyway?
>>>>>>
>>>>>> No you would have to add it as for Unsafe.
>>>>>
>>>>> But it's loaded early anyway as a normal consequence of other 
>>>>> class loading, right?
>>>>
>>>> What do you mean by "early"? It isn't a pre-loaded class but it 
>>>> will be loaded during system initialization. It is approx the 120th 
>>>> class to be loaded. Unsafe is about 135th.
>>>
>>> 120 is earlier than 135, so by that measure it is superior.
>>> Do you see any other problems with the change?
>>> The method's not at all "Unsafe" in the technical sense of the word, 
>>> so it is just a matter of choosing a good home.
>>
>> On further investigation, change to sun.misc.VM would be the first 
>> time that hotspot knows of the existence of sun.misc.VM; 
>> sun.misc.Unsafe is already filled with methods that the runtime knows 
>> about (intrinsics, etc).  I think Unsafe is better.
>
> Okay.
>
> David

Hi David(s),

Excuse me for my ignorance, but does pre-loading the class involve it's 
initialization? Is static initializer called at that time? Even if it is 
not at that time, it surely should be called before first invocation of 
a method on that class (the throwIllegalAccessError() method in this 
case). You need a reference to this method very early - even before 
system initialization starts. How early do you expect first "faulty 
invocations" could occur that need to call this method? What if calling 
that method triggers non-trivial initialization which in turn encounters 
another faulty invocation?

sun.misc.Unsafe has a non-trivial static initialization which involves 
"registerNatives()" native method invocation, and it also calls:

sun.reflect.Reflection.registerMethodsToFilter(Unsafe.class, "getUnsafe");

...which initializes hell lot of things (like java.util.HashMap for 
example, which in who knows which incarnation included random hash seed 
initialization which triggered random number generator initialization 
with gathering of random seed from various sources, ...)

sun.misc.VM on the other hand, only has the following static initialization:

     private static final Object lock = new Object();

     static {
         initialize();
     }
     private native static void initialize();


Are you okay with all possible interactions of this initialization on 
all platforms?

I think a new class with only this method would be a safer choice. 
Regarding back-porting, even if sun.misc.Unsafe is used as the holder 
for that method, this new method will have to be added to 
sun.misc.Unsafe on those legacy platforms in order to obtain this new 
Method *. If the method is not found, the VM would have to behave as 
before. Couldn't the pre-loading of classes be made such that some of 
them are optional?


Regard, Peter

>
>> David
>>