Request for review: 8000797: NPG: is_pseudo_string_at() doesn't work

serguei.spitsyn at serguei.spitsyn at
Thu Feb 21 12:00:27 PST 2013


I like the fix.
It looks good, and you also have done a nice clean-up*!*
The class file reconstitution issue will be tracked by in a separate bug 
report (just filed):
     constant pool reconstitution must support pseudo strings


On 2/20/13 8:11 PM, Coleen Phillimore wrote:
> Thanks to John's feedback, I've modified this change again to revert 
> back to my original change to zero out the Symbol* to indicate pseudo 
> string (could be thought of as "patched string").   Also cleaned up 
> unused constant pool Object constant and unused flags.   Reran all the 
> tests.
> Thanks,
> Coleen
> On 2/20/2013 1:20 PM, Coleen Phillimore wrote:
>> Since nobody replied to my code review request, I modified the change.
>> Summary: Add JVM_CONSTANT_PseudoString in place of 
>> JVM_CONSTANT_Object and use this tag to distinguish patched pseudo 
>> strings. The original string is retained if it was present.
>> I'm not sure how class file reconstitution for pseudo-strings is 
>> going to work, but I thought it was prudent to leave the Symbol* in 
>> the slot for the patched string.
>> I noticed that JVM_CONSTANT_Object is no longer used so reused that 
>> constant to be PseudoString.   I had an edit to go in the other 
>> direction (if a pseudo-string is patched into a constant pool, make 
>> it a JVM_CONSTANT_Object), but this didn't fully capture that the 
>> constant pool slot also points to a Symbol. John or Christian, can 
>> you confirm that you don't plan to use object constants anymore?
>> open webrev at
>> bug link at
>> Tested with vm.quick.testlist (including parallel_class_loading and 
>> mlvm tests) and java/lang/invoke and java/lang/instrument tests.
>> Thanks,
>> Coleen
>> On 2/8/2013 4:59 PM, Coleen Phillimore wrote:
>>> Summary: Null out the original string when patching constant pool 
>>> with pseudo-string
>>> This call is_pseudo_string() conditionalized a pseudo_string_at() 
>>> call, but since it always failed, it went to string_at() which 
>>> returned the same thing.   The only thing that seems to treat 
>>> pseudo-string and regular strings differently is the verifier. The 
>>> verifier pushes an object for pseudo string vs. an object of type 
>>> java/lang/String.
>>> open webrev at
>>> bug link at
>>> Tested with vm.mlvm.testlists and java/lang/invoke tests.
>>> Thanks,
>>> Coleen

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the hotspot-runtime-dev mailing list