You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Li-Gang Wang (JIRA)" <ji...@apache.org> on 2007/06/26 10:01:42 UTC
[jira] Created: (HARMONY-4282) [drlvm][gc] obj_info agreement
between VM and GC
[drlvm][gc] obj_info agreement between VM and GC
------------------------------------------------
Key: HARMONY-4282
URL: https://issues.apache.org/jira/browse/HARMONY-4282
Project: Harmony
Issue Type: Wish
Components: DRLVM
Environment: All
Reporter: Li-Gang Wang
The original assumption on obj_info is new object has no obj_info. But I think this is not convenient or necessarily correct to utilize obj_info sufficiently.
For example, in order to know an object is a small (<= small_threshold) or large (>large_threshold) object, checking a bit in obj_info is more time-saving than searching its size through function vm_object_size. This needs the according bit in obj_info to be set while allocating. But under the original assumption, VM will reset obj_info after allocation sometimes, so that this bit will be misleading. The following is the code resetting obj_info:
jobject object_clone(JNIEnv *jenv, jobject jobj)
{
......
result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
......
memcpy(result, h->object, size); // copy the old object
result->set_obj_info(0); // obj_info is reset here
......
}
I suggest that we'd better modify the original assumption so that VM and GC could manipulate bits in obj_info they are in charge of without interfering each other.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement between VM and GC
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 6/28/07, Gregory Shimansky <gs...@apache.org> wrote:
> Xiao-Feng Li wrote:
> > On 6/28/07, Gregory Shimansky <gs...@apache.org> wrote:
> >> Gregory Shimansky wrote:
> >> > Xiao-Feng Li wrote:
> >> >> Yes, exactly. The newly allocated object may have some bits set in
> >> >> obj_info by GC (only possible for those bits owned by GC). The
> >> >> allocation routine can guarantee the rest bits of obj_info are clear.
> >> >> This situation happens, e.g., when GC sets a property flag in obj_info
> >> >> so as to avoid the re-computation of the property every time using it.
> >> >> One example property flag is whether the object has reference fields;
> >> >> the other example is whether the object is bigger than 4KB; yet
> >> >> another example is, in concurrent GC, the newly allocated object is
> >> >> marked black in obj_info.
> >> >>
> >> >> Basically we want to set up a contract between GC and VM that, object
> >> >> allocation will take care of the object header initialization.
> >> >
> >> > If it is guaranteed that object allocation routine also sets VT pointer
> >> > correctly, then I can prepare a patch (I don't think it should be
> >> > committed before we unfreeze the code) to skip the first
> >> > ManagedObject::get_constant_header_size() bytes when copying memory in
> >> > object_clone() and not reset any information in object header
> >> relying GC
> >> > on the allocation routine.
> >>
> >> BTW, it is necessary that gc_cc also initialize the object header, VT
> >> and obj_info should contain correct information after object is
> >> allocated.
> >
> > Yes, this is actually the default behavior of object allocation. For
> > example, gc_alloc_fast API will return a well-formed object to jitted
> > code without any vt or obj_info manipulation by the jitted code.
>
> I've created a patch in HARMONY-4282. It can be committed when we
> unfreeze the code.
Thanks, I noticed that. Yes, it's not urgent for commit immediately.
> I would also like to know where Object.clone function is used a lot, so
> that I could test the patch. Does anyone know?
I don't know either. This issue was encountered in SPECjbb, but clone
is not frequently used there.
Thanks,
xiaofeng
> --
> Gregory
>
>
--
http://xiao-feng.blogspot.com
Re: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by Gregory Shimansky <gs...@apache.org>.
Xiao-Feng Li wrote:
> On 6/28/07, Gregory Shimansky <gs...@apache.org> wrote:
>> Gregory Shimansky wrote:
>> > Xiao-Feng Li wrote:
>> >> Yes, exactly. The newly allocated object may have some bits set in
>> >> obj_info by GC (only possible for those bits owned by GC). The
>> >> allocation routine can guarantee the rest bits of obj_info are clear.
>> >> This situation happens, e.g., when GC sets a property flag in obj_info
>> >> so as to avoid the re-computation of the property every time using it.
>> >> One example property flag is whether the object has reference fields;
>> >> the other example is whether the object is bigger than 4KB; yet
>> >> another example is, in concurrent GC, the newly allocated object is
>> >> marked black in obj_info.
>> >>
>> >> Basically we want to set up a contract between GC and VM that, object
>> >> allocation will take care of the object header initialization.
>> >
>> > If it is guaranteed that object allocation routine also sets VT pointer
>> > correctly, then I can prepare a patch (I don't think it should be
>> > committed before we unfreeze the code) to skip the first
>> > ManagedObject::get_constant_header_size() bytes when copying memory in
>> > object_clone() and not reset any information in object header
>> relying GC
>> > on the allocation routine.
>>
>> BTW, it is necessary that gc_cc also initialize the object header, VT
>> and obj_info should contain correct information after object is
>> allocated.
>
> Yes, this is actually the default behavior of object allocation. For
> example, gc_alloc_fast API will return a well-formed object to jitted
> code without any vt or obj_info manipulation by the jitted code.
I've created a patch in HARMONY-4282. It can be committed when we
unfreeze the code.
I would also like to know where Object.clone function is used a lot, so
that I could test the patch. Does anyone know?
--
Gregory
Re: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement between VM and GC
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 6/28/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> On 6/28/07, Gregory Shimansky <gs...@apache.org> wrote:
> > Gregory Shimansky wrote:
> > > Xiao-Feng Li wrote:
> > >> Yes, exactly. The newly allocated object may have some bits set in
> > >> obj_info by GC (only possible for those bits owned by GC). The
> > >> allocation routine can guarantee the rest bits of obj_info are clear.
> > >> This situation happens, e.g., when GC sets a property flag in obj_info
> > >> so as to avoid the re-computation of the property every time using it.
> > >> One example property flag is whether the object has reference fields;
> > >> the other example is whether the object is bigger than 4KB; yet
> > >> another example is, in concurrent GC, the newly allocated object is
> > >> marked black in obj_info.
> > >>
> > >> Basically we want to set up a contract between GC and VM that, object
> > >> allocation will take care of the object header initialization.
> > >
> > > If it is guaranteed that object allocation routine also sets VT pointer
> > > correctly, then I can prepare a patch (I don't think it should be
> > > committed before we unfreeze the code) to skip the first
> > > ManagedObject::get_constant_header_size() bytes when copying memory in
> > > object_clone() and not reset any information in object header relying GC
> > > on the allocation routine.
> >
> > BTW, it is necessary that gc_cc also initialize the object header, VT
> > and obj_info should contain correct information after object is allocated.
>
> Yes, this is actually the default behavior of object allocation. For
> example, gc_alloc_fast API will return a well-formed object to jitted
> code without any vt or obj_info manipulation by the jitted code.
Btw, I think the vt and obj_info manipulation in clone() is due to the
fact that it copies the whole object from old to new, including the
object header, where the obj_info might be only valid to the old
object. If we don't copy object header, there is no need for the
obj_info reset.
> Thanks,
> xiaofeng
>
> > >> On 6/27/07, Gregory Shimansky (JIRA) <ji...@apache.org> wrote:
> > >>>
> > >>> [
> > >>> https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508516
> > >>> ]
> > >>>
> > >>> Gregory Shimansky commented on HARMONY-4282:
> > >>> --------------------------------------------
> > >>>
> > >>> There cannot be an object without VT, it can be always copied IMHO.
> > >>> But I think that object allocation already takes care about setting
> > >>> correct pointer to object's VT, so copying it in clone may be redundant.
> > >>>
> > >>> The obj_info field is reset in the GC disabled condition, so no GC is
> > >>> possible at this moment. Do you mean that some of the last 10 bits
> > >>> may be set in the newly allocated object and VM clears them? What is
> > >>> the value of obj_info after allocation is done? Are the higher 22
> > >>> bits clear? If yes, then clearing them is not required.
> > >>>
> > >>> > [drlvm][vmcore] obj_info agreement between VM and GC
> > >>> > ----------------------------------------------------
> > >>> >
> > >>> > Key: HARMONY-4282
> > >>> > URL:
> > >>> https://issues.apache.org/jira/browse/HARMONY-4282
> > >>> > Project: Harmony
> > >>> > Issue Type: Bug
> > >>> > Components: DRLVM
> > >>> > Environment: All
> > >>> > Reporter: Li-Gang Wang
> > >>> > Assignee: Gregory Shimansky
> > >>> >
> > >>> > I found some issue with obj_info initialization protocol between VM
> > >>> and GC.
> > >>> > Since there is a partitioning of the obj_info bits between VM and
> > >>> GC (GC takes the last 10 bits), VM should not touch the last 10 bits
> > >>> without strong argument. But in following piece of code, VM assumes
> > >>> the obj_info is empty after the object is allocated. This code makes
> > >>> some GC design impossible.
> > >>> > jobject object_clone(JNIEnv *jenv, jobject jobj)
> > >>> > {
> > >>> > ......
> > >>> > result =
> > >>> (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length,
> > >>> vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); //
> > >>> call gc_alloc
> > >>> > ......
> > >>> > memcpy(result, h->object, size); // copy the old object
> > >>> > result->set_obj_info(0); // obj_info is reset
> > >>> here
> > >>> > ......
> > >>> > }
> > >>> > This code should be changed to remove the obj_info reset statement,
> > >>> and the memcpy should copy only the object fields part, excluding the
> > >>> object header (vt and obj_info).
> > >>>
> > >>> --
> > >>> This message is automatically generated by JIRA.
> > >>> -
> > >>> You can reply to this email to add a comment to the issue online.
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > Gregory
> >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
--
http://xiao-feng.blogspot.com
Re: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement between VM and GC
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 6/28/07, Gregory Shimansky <gs...@apache.org> wrote:
> Gregory Shimansky wrote:
> > Xiao-Feng Li wrote:
> >> Yes, exactly. The newly allocated object may have some bits set in
> >> obj_info by GC (only possible for those bits owned by GC). The
> >> allocation routine can guarantee the rest bits of obj_info are clear.
> >> This situation happens, e.g., when GC sets a property flag in obj_info
> >> so as to avoid the re-computation of the property every time using it.
> >> One example property flag is whether the object has reference fields;
> >> the other example is whether the object is bigger than 4KB; yet
> >> another example is, in concurrent GC, the newly allocated object is
> >> marked black in obj_info.
> >>
> >> Basically we want to set up a contract between GC and VM that, object
> >> allocation will take care of the object header initialization.
> >
> > If it is guaranteed that object allocation routine also sets VT pointer
> > correctly, then I can prepare a patch (I don't think it should be
> > committed before we unfreeze the code) to skip the first
> > ManagedObject::get_constant_header_size() bytes when copying memory in
> > object_clone() and not reset any information in object header relying GC
> > on the allocation routine.
>
> BTW, it is necessary that gc_cc also initialize the object header, VT
> and obj_info should contain correct information after object is allocated.
Yes, this is actually the default behavior of object allocation. For
example, gc_alloc_fast API will return a well-formed object to jitted
code without any vt or obj_info manipulation by the jitted code.
Thanks,
xiaofeng
> >> On 6/27/07, Gregory Shimansky (JIRA) <ji...@apache.org> wrote:
> >>>
> >>> [
> >>> https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508516
> >>> ]
> >>>
> >>> Gregory Shimansky commented on HARMONY-4282:
> >>> --------------------------------------------
> >>>
> >>> There cannot be an object without VT, it can be always copied IMHO.
> >>> But I think that object allocation already takes care about setting
> >>> correct pointer to object's VT, so copying it in clone may be redundant.
> >>>
> >>> The obj_info field is reset in the GC disabled condition, so no GC is
> >>> possible at this moment. Do you mean that some of the last 10 bits
> >>> may be set in the newly allocated object and VM clears them? What is
> >>> the value of obj_info after allocation is done? Are the higher 22
> >>> bits clear? If yes, then clearing them is not required.
> >>>
> >>> > [drlvm][vmcore] obj_info agreement between VM and GC
> >>> > ----------------------------------------------------
> >>> >
> >>> > Key: HARMONY-4282
> >>> > URL:
> >>> https://issues.apache.org/jira/browse/HARMONY-4282
> >>> > Project: Harmony
> >>> > Issue Type: Bug
> >>> > Components: DRLVM
> >>> > Environment: All
> >>> > Reporter: Li-Gang Wang
> >>> > Assignee: Gregory Shimansky
> >>> >
> >>> > I found some issue with obj_info initialization protocol between VM
> >>> and GC.
> >>> > Since there is a partitioning of the obj_info bits between VM and
> >>> GC (GC takes the last 10 bits), VM should not touch the last 10 bits
> >>> without strong argument. But in following piece of code, VM assumes
> >>> the obj_info is empty after the object is allocated. This code makes
> >>> some GC design impossible.
> >>> > jobject object_clone(JNIEnv *jenv, jobject jobj)
> >>> > {
> >>> > ......
> >>> > result =
> >>> (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length,
> >>> vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); //
> >>> call gc_alloc
> >>> > ......
> >>> > memcpy(result, h->object, size); // copy the old object
> >>> > result->set_obj_info(0); // obj_info is reset
> >>> here
> >>> > ......
> >>> > }
> >>> > This code should be changed to remove the obj_info reset statement,
> >>> and the memcpy should copy only the object fields part, excluding the
> >>> object header (vt and obj_info).
> >>>
> >>> --
> >>> This message is automatically generated by JIRA.
> >>> -
> >>> You can reply to this email to add a comment to the issue online.
> >>>
> >>>
> >>
> >>
> >
> >
>
>
> --
> Gregory
>
>
--
http://xiao-feng.blogspot.com
Re: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by Gregory Shimansky <gs...@apache.org>.
Gregory Shimansky wrote:
> Xiao-Feng Li wrote:
>> Yes, exactly. The newly allocated object may have some bits set in
>> obj_info by GC (only possible for those bits owned by GC). The
>> allocation routine can guarantee the rest bits of obj_info are clear.
>> This situation happens, e.g., when GC sets a property flag in obj_info
>> so as to avoid the re-computation of the property every time using it.
>> One example property flag is whether the object has reference fields;
>> the other example is whether the object is bigger than 4KB; yet
>> another example is, in concurrent GC, the newly allocated object is
>> marked black in obj_info.
>>
>> Basically we want to set up a contract between GC and VM that, object
>> allocation will take care of the object header initialization.
>
> If it is guaranteed that object allocation routine also sets VT pointer
> correctly, then I can prepare a patch (I don't think it should be
> committed before we unfreeze the code) to skip the first
> ManagedObject::get_constant_header_size() bytes when copying memory in
> object_clone() and not reset any information in object header relying GC
> on the allocation routine.
BTW, it is necessary that gc_cc also initialize the object header, VT
and obj_info should contain correct information after object is allocated.
>> On 6/27/07, Gregory Shimansky (JIRA) <ji...@apache.org> wrote:
>>>
>>> [
>>> https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508516
>>> ]
>>>
>>> Gregory Shimansky commented on HARMONY-4282:
>>> --------------------------------------------
>>>
>>> There cannot be an object without VT, it can be always copied IMHO.
>>> But I think that object allocation already takes care about setting
>>> correct pointer to object's VT, so copying it in clone may be redundant.
>>>
>>> The obj_info field is reset in the GC disabled condition, so no GC is
>>> possible at this moment. Do you mean that some of the last 10 bits
>>> may be set in the newly allocated object and VM clears them? What is
>>> the value of obj_info after allocation is done? Are the higher 22
>>> bits clear? If yes, then clearing them is not required.
>>>
>>> > [drlvm][vmcore] obj_info agreement between VM and GC
>>> > ----------------------------------------------------
>>> >
>>> > Key: HARMONY-4282
>>> > URL:
>>> https://issues.apache.org/jira/browse/HARMONY-4282
>>> > Project: Harmony
>>> > Issue Type: Bug
>>> > Components: DRLVM
>>> > Environment: All
>>> > Reporter: Li-Gang Wang
>>> > Assignee: Gregory Shimansky
>>> >
>>> > I found some issue with obj_info initialization protocol between VM
>>> and GC.
>>> > Since there is a partitioning of the obj_info bits between VM and
>>> GC (GC takes the last 10 bits), VM should not touch the last 10 bits
>>> without strong argument. But in following piece of code, VM assumes
>>> the obj_info is empty after the object is allocated. This code makes
>>> some GC design impossible.
>>> > jobject object_clone(JNIEnv *jenv, jobject jobj)
>>> > {
>>> > ......
>>> > result =
>>> (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length,
>>> vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); //
>>> call gc_alloc
>>> > ......
>>> > memcpy(result, h->object, size); // copy the old object
>>> > result->set_obj_info(0); // obj_info is reset
>>> here
>>> > ......
>>> > }
>>> > This code should be changed to remove the obj_info reset statement,
>>> and the memcpy should copy only the object fields part, excluding the
>>> object header (vt and obj_info).
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>
>>
>
>
--
Gregory
Re: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by Gregory Shimansky <gs...@apache.org>.
Xiao-Feng Li wrote:
> Yes, exactly. The newly allocated object may have some bits set in
> obj_info by GC (only possible for those bits owned by GC). The
> allocation routine can guarantee the rest bits of obj_info are clear.
> This situation happens, e.g., when GC sets a property flag in obj_info
> so as to avoid the re-computation of the property every time using it.
> One example property flag is whether the object has reference fields;
> the other example is whether the object is bigger than 4KB; yet
> another example is, in concurrent GC, the newly allocated object is
> marked black in obj_info.
>
> Basically we want to set up a contract between GC and VM that, object
> allocation will take care of the object header initialization.
If it is guaranteed that object allocation routine also sets VT pointer
correctly, then I can prepare a patch (I don't think it should be
committed before we unfreeze the code) to skip the first
ManagedObject::get_constant_header_size() bytes when copying memory in
object_clone() and not reset any information in object header relying GC
on the allocation routine.
> On 6/27/07, Gregory Shimansky (JIRA) <ji...@apache.org> wrote:
>>
>> [
>> https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508516
>> ]
>>
>> Gregory Shimansky commented on HARMONY-4282:
>> --------------------------------------------
>>
>> There cannot be an object without VT, it can be always copied IMHO.
>> But I think that object allocation already takes care about setting
>> correct pointer to object's VT, so copying it in clone may be redundant.
>>
>> The obj_info field is reset in the GC disabled condition, so no GC is
>> possible at this moment. Do you mean that some of the last 10 bits may
>> be set in the newly allocated object and VM clears them? What is the
>> value of obj_info after allocation is done? Are the higher 22 bits
>> clear? If yes, then clearing them is not required.
>>
>> > [drlvm][vmcore] obj_info agreement between VM and GC
>> > ----------------------------------------------------
>> >
>> > Key: HARMONY-4282
>> > URL: https://issues.apache.org/jira/browse/HARMONY-4282
>> > Project: Harmony
>> > Issue Type: Bug
>> > Components: DRLVM
>> > Environment: All
>> > Reporter: Li-Gang Wang
>> > Assignee: Gregory Shimansky
>> >
>> > I found some issue with obj_info initialization protocol between VM
>> and GC.
>> > Since there is a partitioning of the obj_info bits between VM and GC
>> (GC takes the last 10 bits), VM should not touch the last 10 bits
>> without strong argument. But in following piece of code, VM assumes
>> the obj_info is empty after the object is allocated. This code makes
>> some GC design impossible.
>> > jobject object_clone(JNIEnv *jenv, jobject jobj)
>> > {
>> > ......
>> > result =
>> (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length,
>> vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); //
>> call gc_alloc
>> > ......
>> > memcpy(result, h->object, size); // copy the old object
>> > result->set_obj_info(0); // obj_info is reset here
>> > ......
>> > }
>> > This code should be changed to remove the obj_info reset statement,
>> and the memcpy should copy only the object fields part, excluding the
>> object header (vt and obj_info).
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>
>
--
Gregory
Re: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement between VM and GC
Posted by Xiao-Feng Li <xi...@gmail.com>.
Yes, exactly. The newly allocated object may have some bits set in
obj_info by GC (only possible for those bits owned by GC). The
allocation routine can guarantee the rest bits of obj_info are clear.
This situation happens, e.g., when GC sets a property flag in obj_info
so as to avoid the re-computation of the property every time using it.
One example property flag is whether the object has reference fields;
the other example is whether the object is bigger than 4KB; yet
another example is, in concurrent GC, the newly allocated object is
marked black in obj_info.
Basically we want to set up a contract between GC and VM that, object
allocation will take care of the object header initialization.
Thanks,
xiaofeng
On 6/27/07, Gregory Shimansky (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508516 ]
>
> Gregory Shimansky commented on HARMONY-4282:
> --------------------------------------------
>
> There cannot be an object without VT, it can be always copied IMHO. But I think that object allocation already takes care about setting correct pointer to object's VT, so copying it in clone may be redundant.
>
> The obj_info field is reset in the GC disabled condition, so no GC is possible at this moment. Do you mean that some of the last 10 bits may be set in the newly allocated object and VM clears them? What is the value of obj_info after allocation is done? Are the higher 22 bits clear? If yes, then clearing them is not required.
>
> > [drlvm][vmcore] obj_info agreement between VM and GC
> > ----------------------------------------------------
> >
> > Key: HARMONY-4282
> > URL: https://issues.apache.org/jira/browse/HARMONY-4282
> > Project: Harmony
> > Issue Type: Bug
> > Components: DRLVM
> > Environment: All
> > Reporter: Li-Gang Wang
> > Assignee: Gregory Shimansky
> >
> > I found some issue with obj_info initialization protocol between VM and GC.
> > Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> > jobject object_clone(JNIEnv *jenv, jobject jobj)
> > {
> > ......
> > result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> > ......
> > memcpy(result, h->object, size); // copy the old object
> > result->set_obj_info(0); // obj_info is reset here
> > ......
> > }
> > This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
http://xiao-feng.blogspot.com
Re: [jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement between VM and GC
Posted by Xiao-Feng Li <xi...@gmail.com>.
Yes, exactly. The newly allocated object may have some bits set in
obj_info by GC (only possible for those bits owned by GC). The
allocation routine can guarantee the rest bits of obj_info are clear.
This situation happens, e.g., when GC sets a property flag in obj_info
so as to avoid the re-computation of the property every time using it.
One example property flag is whether the object has reference fields;
the other example is whether the object is bigger than 4KB; yet
another example is, in concurrent GC, the newly allocated object is
marked black in obj_info.
Basically we want to set up a contract between GC and VM that, object
allocation will take care of the object header initialization.
Thanks,
xiaofeng
On 6/27/07, Gregory Shimansky (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508516 ]
>
> Gregory Shimansky commented on HARMONY-4282:
> --------------------------------------------
>
> There cannot be an object without VT, it can be always copied IMHO. But I think that object allocation already takes care about setting correct pointer to object's VT, so copying it in clone may be redundant.
>
> The obj_info field is reset in the GC disabled condition, so no GC is possible at this moment. Do you mean that some of the last 10 bits may be set in the newly allocated object and VM clears them? What is the value of obj_info after allocation is done? Are the higher 22 bits clear? If yes, then clearing them is not required.
>
> > [drlvm][vmcore] obj_info agreement between VM and GC
> > ----------------------------------------------------
> >
> > Key: HARMONY-4282
> > URL: https://issues.apache.org/jira/browse/HARMONY-4282
> > Project: Harmony
> > Issue Type: Bug
> > Components: DRLVM
> > Environment: All
> > Reporter: Li-Gang Wang
> > Assignee: Gregory Shimansky
> >
> > I found some issue with obj_info initialization protocol between VM and GC.
> > Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> > jobject object_clone(JNIEnv *jenv, jobject jobj)
> > {
> > ......
> > result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> > ......
> > memcpy(result, h->object, size); // copy the old object
> > result->set_obj_info(0); // obj_info is reset here
> > ......
> > }
> > This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
http://xiao-feng.blogspot.com
[jira] Updated: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky updated HARMONY-4282:
---------------------------------------
Attachment: HARMONY-4282.patch
Attached patch fixes Object.clone not to copy VT and obj_info files from the source object. GC should make sure that they are initialized correctly at object's allocation time. This includes both gcv5 and gc41 for drlvm.
I've ran classlib's security tests which allegedly utilize Object.clone function and all tests passed. I wonder about other workloads which could use Object.clone to test that it works correctly.
Patch shouldn't be committed before M2 milestone passes.
> [drlvm][vmcore] obj_info agreement between VM and GC
> ----------------------------------------------------
>
> Key: HARMONY-4282
> URL: https://issues.apache.org/jira/browse/HARMONY-4282
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: All
> Reporter: Li-Gang Wang
> Assignee: Gregory Shimansky
> Attachments: HARMONY-4282.patch
>
>
> I found some issue with obj_info initialization protocol between VM and GC.
> Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> jobject object_clone(JNIEnv *jenv, jobject jobj)
> {
> ......
> result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> ......
> memcpy(result, h->object, size); // copy the old object
> result->set_obj_info(0); // obj_info is reset here
> ......
> }
> This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xiao-Feng Li reassigned HARMONY-4282:
-------------------------------------
Assignee: Gregory Shimansky (was: Xiao-Feng Li)
reassign it to Gregory as a VM guru.
> [drlvm][vmcore] obj_info agreement between VM and GC
> ----------------------------------------------------
>
> Key: HARMONY-4282
> URL: https://issues.apache.org/jira/browse/HARMONY-4282
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: All
> Reporter: Li-Gang Wang
> Assignee: Gregory Shimansky
>
> I found some issue with obj_info initialization protocol between VM and GC.
> Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> jobject object_clone(JNIEnv *jenv, jobject jobj)
> {
> ......
> result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> ......
> memcpy(result, h->object, size); // copy the old object
> result->set_obj_info(0); // obj_info is reset here
> ......
> }
> This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky updated HARMONY-4282:
---------------------------------------
Attachment: HARMONY-4282.patch
Reattached file with ASF license granted.
> [drlvm][vmcore] obj_info agreement between VM and GC
> ----------------------------------------------------
>
> Key: HARMONY-4282
> URL: https://issues.apache.org/jira/browse/HARMONY-4282
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: All
> Reporter: Li-Gang Wang
> Assignee: Gregory Shimansky
> Attachments: HARMONY-4282.patch
>
>
> I found some issue with obj_info initialization protocol between VM and GC.
> Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> jobject object_clone(JNIEnv *jenv, jobject jobj)
> {
> ......
> result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> ......
> memcpy(result, h->object, size); // copy the old object
> result->set_obj_info(0); // obj_info is reset here
> ......
> }
> This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508824 ]
Xiao-Feng Li commented on HARMONY-4282:
---------------------------------------
Yes, exactly. The newly allocated object may have some bits set in
obj_info by GC (only possible for those bits owned by GC). The
allocation routine can guarantee the rest bits of obj_info are clear.
This situation happens, e.g., when GC sets a property flag in obj_info
so as to avoid the re-computation of the property every time using it.
One example property flag is whether the object has reference fields;
the other example is whether the object is bigger than 4KB; yet
another example is, in concurrent GC, the newly allocated object is
marked black in obj_info.
Basically we want to set up a contract between GC and VM that, object
allocation will take care of the object header initialization.
Thanks,
xiaofeng
--
http://xiao-feng.blogspot.com
> [drlvm][vmcore] obj_info agreement between VM and GC
> ----------------------------------------------------
>
> Key: HARMONY-4282
> URL: https://issues.apache.org/jira/browse/HARMONY-4282
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: All
> Reporter: Li-Gang Wang
> Assignee: Gregory Shimansky
>
> I found some issue with obj_info initialization protocol between VM and GC.
> Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> jobject object_clone(JNIEnv *jenv, jobject jobj)
> {
> ......
> result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> ......
> memcpy(result, h->object, size); // copy the old object
> result->set_obj_info(0); // obj_info is reset here
> ......
> }
> This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-4282) [drlvm][gc] obj_info agreement
between VM and GC
Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xiao-Feng Li reassigned HARMONY-4282:
-------------------------------------
Assignee: Xiao-Feng Li
> [drlvm][gc] obj_info agreement between VM and GC
> ------------------------------------------------
>
> Key: HARMONY-4282
> URL: https://issues.apache.org/jira/browse/HARMONY-4282
> Project: Harmony
> Issue Type: Wish
> Components: DRLVM
> Environment: All
> Reporter: Li-Gang Wang
> Assignee: Xiao-Feng Li
>
> The original assumption on obj_info is new object has no obj_info. But I think this is not convenient or necessarily correct to utilize obj_info sufficiently.
> For example, in order to know an object is a small (<= small_threshold) or large (>large_threshold) object, checking a bit in obj_info is more time-saving than searching its size through function vm_object_size. This needs the according bit in obj_info to be set while allocating. But under the original assumption, VM will reset obj_info after allocation sometimes, so that this bit will be misleading. The following is the code resetting obj_info:
> jobject object_clone(JNIEnv *jenv, jobject jobj)
> {
> ......
> result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> ......
> memcpy(result, h->object, size); // copy the old object
> result->set_obj_info(0); // obj_info is reset here
> ......
> }
> I suggest that we'd better modify the original assumption so that VM and GC could manipulate bits in obj_info they are in charge of without interfering each other.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508516 ]
Gregory Shimansky commented on HARMONY-4282:
--------------------------------------------
There cannot be an object without VT, it can be always copied IMHO. But I think that object allocation already takes care about setting correct pointer to object's VT, so copying it in clone may be redundant.
The obj_info field is reset in the GC disabled condition, so no GC is possible at this moment. Do you mean that some of the last 10 bits may be set in the newly allocated object and VM clears them? What is the value of obj_info after allocation is done? Are the higher 22 bits clear? If yes, then clearing them is not required.
> [drlvm][vmcore] obj_info agreement between VM and GC
> ----------------------------------------------------
>
> Key: HARMONY-4282
> URL: https://issues.apache.org/jira/browse/HARMONY-4282
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: All
> Reporter: Li-Gang Wang
> Assignee: Gregory Shimansky
>
> I found some issue with obj_info initialization protocol between VM and GC.
> Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> jobject object_clone(JNIEnv *jenv, jobject jobj)
> {
> ......
> result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> ......
> memcpy(result, h->object, size); // copy the old object
> result->set_obj_info(0); // obj_info is reset here
> ......
> }
> This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky resolved HARMONY-4282.
----------------------------------------
Resolution: Fixed
Patch is applied at 559583. Please check that the bug is fixed for you.
> [drlvm][vmcore] obj_info agreement between VM and GC
> ----------------------------------------------------
>
> Key: HARMONY-4282
> URL: https://issues.apache.org/jira/browse/HARMONY-4282
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: All
> Reporter: Li-Gang Wang
> Assignee: Gregory Shimansky
> Attachments: HARMONY-4282.patch
>
>
> I found some issue with obj_info initialization protocol between VM and GC.
> Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> jobject object_clone(JNIEnv *jenv, jobject jobj)
> {
> ......
> result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> ......
> memcpy(result, h->object, size); // copy the old object
> result->set_obj_info(0); // obj_info is reset here
> ......
> }
> This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky updated HARMONY-4282:
---------------------------------------
Attachment: (was: HARMONY-4282.patch)
> [drlvm][vmcore] obj_info agreement between VM and GC
> ----------------------------------------------------
>
> Key: HARMONY-4282
> URL: https://issues.apache.org/jira/browse/HARMONY-4282
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: All
> Reporter: Li-Gang Wang
> Assignee: Gregory Shimansky
> Attachments: HARMONY-4282.patch
>
>
> I found some issue with obj_info initialization protocol between VM and GC.
> Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> jobject object_clone(JNIEnv *jenv, jobject jobj)
> {
> ......
> result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> ......
> memcpy(result, h->object, size); // copy the old object
> result->set_obj_info(0); // obj_info is reset here
> ......
> }
> This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky closed HARMONY-4282.
--------------------------------------
No response, assuming ok.
> [drlvm][vmcore] obj_info agreement between VM and GC
> ----------------------------------------------------
>
> Key: HARMONY-4282
> URL: https://issues.apache.org/jira/browse/HARMONY-4282
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: All
> Reporter: Li-Gang Wang
> Assignee: Gregory Shimansky
> Attachments: HARMONY-4282.patch
>
>
> I found some issue with obj_info initialization protocol between VM and GC.
> Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> jobject object_clone(JNIEnv *jenv, jobject jobj)
> {
> ......
> result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> ......
> memcpy(result, h->object, size); // copy the old object
> result->set_obj_info(0); // obj_info is reset here
> ......
> }
> This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4282) [drlvm][vmcore] obj_info agreement
between VM and GC
Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xiao-Feng Li updated HARMONY-4282:
----------------------------------
Description:
I found some issue with obj_info initialization protocol between VM and GC.
Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
jobject object_clone(JNIEnv *jenv, jobject jobj)
{
......
result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
......
memcpy(result, h->object, size); // copy the old object
result->set_obj_info(0); // obj_info is reset here
......
}
This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
was:
The original assumption on obj_info is new object has no obj_info. But I think this is not convenient or necessarily correct to utilize obj_info sufficiently.
For example, in order to know an object is a small (<= small_threshold) or large (>large_threshold) object, checking a bit in obj_info is more time-saving than searching its size through function vm_object_size. This needs the according bit in obj_info to be set while allocating. But under the original assumption, VM will reset obj_info after allocation sometimes, so that this bit will be misleading. The following is the code resetting obj_info:
jobject object_clone(JNIEnv *jenv, jobject jobj)
{
......
result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
......
memcpy(result, h->object, size); // copy the old object
result->set_obj_info(0); // obj_info is reset here
......
}
I suggest that we'd better modify the original assumption so that VM and GC could manipulate bits in obj_info they are in charge of without interfering each other.
Patch Info: (was: [Patch Available])
Issue Type: Bug (was: Wish)
Summary: [drlvm][vmcore] obj_info agreement between VM and GC (was: [drlvm][gc] obj_info agreement between VM and GC)
> [drlvm][vmcore] obj_info agreement between VM and GC
> ----------------------------------------------------
>
> Key: HARMONY-4282
> URL: https://issues.apache.org/jira/browse/HARMONY-4282
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: All
> Reporter: Li-Gang Wang
> Assignee: Xiao-Feng Li
>
> I found some issue with obj_info initialization protocol between VM and GC.
> Since there is a partitioning of the obj_info bits between VM and GC (GC takes the last 10 bits), VM should not touch the last 10 bits without strong argument. But in following piece of code, VM assumes the obj_info is empty after the object is allocated. This code makes some GC design impossible.
> jobject object_clone(JNIEnv *jenv, jobject jobj)
> {
> ......
> result = (ManagedObject*)vm_new_vector_using_vtable_and_thread_pointer(length, vt->clss->get_allocation_handle(), vm_get_gc_thread_local()); // call gc_alloc
> ......
> memcpy(result, h->object, size); // copy the old object
> result->set_obj_info(0); // obj_info is reset here
> ......
> }
> This code should be changed to remove the obj_info reset statement, and the memcpy should copy only the object fields part, excluding the object header (vt and obj_info).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.