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