for review (M): 6863023: need non-perm oops in code cache for JSR 292

Vladimir Kozlov Vladimir.Kozlov at Sun.COM
Fri Jul 31 09:58:07 PDT 2009


John,

I did not find anything alarming.

Could you rename non_perm_state_clean() to non_perm_not_marked()
or something otherwise the next code looks strange since
the non_perm_state is also used to flag "on list" state:

+     debug_only(cur->clear_non_perm_marked());
+     assert(cur->non_perm_state_clean(), "");
+     assert(cur->on_non_perm_list(), "else shouldn't be on this list");

In nmethod.hpp could you move enum above its usage and use it in
on_non_perm_list()?

Can you change the comment in parse3.cpp to next?:

     // cases:
     //   should_be_constant = (oop == null || oop in perm space || NonPermCodeRefs >= 2)
     //   has_encoding       = (should_be_constant || NonPermCodeRefs == 1)
     //

In globals.hpp it would be better to have "1: allow" on a separate line.

Thanks,
Vladimir

John Rose wrote:
> I have updated the webrev slightly, and fixed the URL:
>   http://cr.openjdk.java.net/~jrose/6863023/webrev.01/
> 
> Someone observed that the pruning logic might not be exercised, since 
> non-perms do not become perm.  But it does get exercised when nmethods 
> are deallocated.  (And that caused a bug I had to fix...)
> 
> -- John
> 
> On Jul 28, 2009, at 7:08 PM, John Rose wrote:
> 
>> On Jul 27, 2009, at 4:10 AM, Christian Thalinger wrote:
>>
>>> It seems there is a problem with returns:
>>
>> Right; it was an incomplete code change.  Thanks.  -- John
> 



More information about the hotspot-compiler-dev mailing list