6354181 and the SystemDictionary

John Rose john.r.rose at oracle.com
Wed Jan 26 14:38:06 PST 2011


On Jan 26, 2011, at 1:55 PM, Tom Rodriguez wrote:

>> So I have only walked through the find_constrained_instance_or_array_klass once and I
>> believe it is only called in ciEnv::get_klass_by_name_impl, and only if "require_local" is false.
>> I was unable to figure out the real meaning behind require_local.
> 
> It controls whether to restrict the lookup to klasses which can be reached directly through the constant pool.  If it's false then we try to find the klass in a symbolic fashion.  This helps deal with types that haven't be resolved yet or types which are never referenced from the constant pool, like the types in the method signature.

If require_local==true, the CI sticks to what the interpreter would see in the resolved state, if it looked at the caller class's constant pool.  If require_local==false, the net is cast more widely as Tom says.  Basically, if we can cleverly predict what the the local CP entry *would* resolve to *eventually*, we take that result and use it.  Doing this prevents lots of useless dead ends in optimized code.

>> So I think the modification would be in find_constrained_instance_or_array_klass to only return
>> classes in the loaded state, or arrays for which the element class is in the loaded state,
>> as you suggest.
> 
> Yes that was helpful.  I'll go with the fix in find_constrained_instance_or_array_klass.

That's my advice too.  If "find_constrained_*" is trying to look into the future, and the constrained class is not yet fully loaded, then the future is not yet determined.  So "find_constrained_*" should fail to make such a prediction, and return null.

Thank for looking into this.

-- John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110126/92643cbf/attachment.html 


More information about the hotspot-runtime-dev mailing list