Pavel, thanks. Since the semantic of newInstance or alloc_instance or gc_alloc(_fast) itself doesn't actually use NEXT_TO_HIGH_BIT, no matter it is written in Java or other languages, I think NSO will not use it either. Do you think so? Or would you tell me how NSO will use NEXT_TO_HIGH_BIT?
Thanks, xiaofeng On 3/21/07, Pavel Pervov <[EMAIL PROTECTED]> wrote:
"is now implemented" it was supposed to be written. :) On 3/21/07, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > It is indirectly used in the NSO for Class.newInstance. But this code is > not currently executed, since Class.newInstance is not implemented in > Java. > > WBR, > Pavel. > On 3/21/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > Pavel, Thanks for your reply. > > > > Would let me know how NEXT_TO_HIGH_BIT is used currently in DRLVM? Or > > in other words, what functionalities are dependent on > > NEXT_TO_HIGH_BIT? > > > > Thanks, > > xiaofeng > > > > On 3/21/07, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > > Xiao-Feng, > > > > > > All the infructructure is in place. It is just do not work at the > > moment. > > > As Class.newInstance is not native, NSO does not replace it's > > implementation > > > with VM's stub. > > > If NEXT_TO_HIGH_BIT-supporting code is to be removed, the rest of the > > code > > > (NSO implementations for ia32 and ia64) has to be removed altogether > > to not > > > provoke any errors in the future. > > > > > > Does removing NSO overrides for Class.newInstance look reasonable for > > you? > > > > > > WBR, > > > Pavel. > > > > > > On 3/21/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > > > > > If no one objects, I will try to remove this flag in DRLVM. > > > > > > > > Thanks, > > > > xiaofeng > > > > > > > > On 3/21/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > > Hi, the source code for class preparation calls > > > > > set_instance_data_size_constraint_bit() for three situations: > > special > > > > > alignment requirement, having finalizer, and to be pinned. And the > > > > > comments there say the constraint bit is for GC to understand. > > > > > > > > > > But current GC actually doesn't care about this bit, and simply > > masks > > > > > it off. Does anybody know what are the situations for the size > > > > > constraint bit to be set for allocation? > > > > > > > > > > I recall this kind of constraint bit was ORP legacy, when the > > > > > intention was for gc_alloc_fast to be really fast, avoiding any > > > > > special allocation treatment. So once the big flag is set, > > > > > gc_alloc_fast will simply return NULL, and the VM will invoke > > gc_alloc > > > > > to accomplish the allocation. > > > > > > > > > > Now DRLVM has different processing, and the GC doesn't use the > > flag in > > > > > size for allocation. I wonder what is the real purpose of this > > size > > > > > flag in allocation. > > > > > > > > > > Thanks, > > > > > xiaofeng > > > > > > > > > > > > > > > > > > > > > -- > > > Pavel Pervov, > > > Intel Enterprise Solutions Software Division > > > > > > > > > -- > Pavel Pervov, > Intel Enterprise Solutions Software Division > -- Pavel Pervov, Intel Enterprise Solutions Software Division
