You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stepan Mishura <st...@gmail.com> on 2006/12/13 07:27:52 UTC
[classlib][luni] update for bootstrapClassPath causes regression on DRL VM (was: Re: [drlvm][classlib] CC is failed to run classlib tests over the DRLVM)
Gregory and Oliver,
Could you have a look on your update to luniglob.c? It causes classlib test
failures on DRL VM. So if I rollback your update all classlib test pass for
me.
Index: modules/luni/src/main/native/luni/shared/luniglob.c
===================================================================
--- modules/luni/src/main/native/luni/shared/luniglob.c (revision 486504)
+++ modules/luni/src/main/native/luni/shared/luniglob.c (working copy)
@@ -268,16 +268,8 @@
unsigned i = 0;
/* Make a string version of the CP separator */
char cpSeparator[] = {(char)hysysinfo_get_classpathSeparator (),
'\0'};
-
- /* Read current value of bootclasspath property */
- rcGetProperty = (*vmInterface)->GetSystemProperty (vmInterface,
- BOOTCLASSPATH_PROPERTY,
- &bootstrapClassPath);
+ bootstrapClassPath = "";
- /* Gregory - no property is found, VM bootclasspath is not defined
*/
- if (VMI_ERROR_NONE != rcGetProperty)
- bootstrapClassPath = NULL;
-
qsort(props, number, sizeof(key_value_pair), props_compare);
for (;i < number; i++)
Thanks,
Stepan.
On 12/13/06, Stepan Mishura wrote:
> On 12/13/06, Vladimir Ivanov wrote:
> >
> > CC is failed to run classlib tests over the DRLVM won windows and linux
> > with
> > messages:
> >
> > Unit Test Error Details: (581) Test: testGetAccessibleAction
> > Class:
> > java.awt.AccessibleAWTCheckboxMenuItemTest
> > java.lang.NoClassDefFoundError: javax/accessibility/Accessible Test:
> > testGetAccessibleRole Class: java.awt.AccessibleAWTCheckboxMenuItemTest
> > java.lang.NoClassDefFoundError : javax/accessibility/Accessible
> > Could somebody reproduce it?
>
>
> I can reproduce it. It seems that a cause is update for bootstrapClassPath
> in modules/luni/src/main/native/luni/shared/luniglob.c (r486100-486378).
>
> I've rolled back them localy and this resolved classlib tests failures on
> DRL VM.
>
> Thanks,
> Stepan
>
--
Stepan Mishura
Intel Enterprise Solutions Software Division
Re: [classlib][luni] update for bootstrapClassPath causes regression
on DRL VM
Posted by Gregory Shimansky <gs...@gmail.com>.
Oliver Deakin wrote:
> Tim Ellison wrote:
>> Geir Magnusson Jr. wrote:
>>
>>> Do we really have a problem? Or is it something else?
>>>
>>> Last night, Gregory tested his fix, and I've build snapshots (r486417)
>>> on x86 linux/win and x86_64 linux and spot checked with apps and such,
>>> and things seem to work.
>>>
>>> I'n posting the snapshots now to ~geirm and will send a separate note
>>> for people to evaluate.
>>>
>>
>> Also catching up on mail. I suggested (on the other thread) that we
>> need to define the return result for undefined properties, answering
>> NULL seemed reasonable, but now I look at the vmiError enum in vmi.h it
>> appears that we have already defined:
>> "VMI_ERROR_NOT_FOUND -- The requested system property was not found"
>>
>>
>
> This surprises me slightly - I would have imagined we would want to work
> in a similar way
> to the System.getSystem() method and return NULL in the case of a
> non-existent property
> being requested. However, it appears that GetSystemProperty() is
> intended to return
> VMI_ERROR_NOT_FOUND in this case.
>
> I would say that since the function behaviour in this case has not yet
> been clearly spec'ed
> (and we have two VMs that behave differently) we should make a choice
> now about which
> return is correct and fix up the VMs. So, should we just return a NULL
> property value and
> no error code, or return VMI_ERROR_NOT_FOUND?
I think we have a freedom to change constants specification, and so we
can change the comment for VMI_ERROR_NOT_FOUND so that it doesn't
mention system properties. If we agree on this, I'll change VMI
implementation in drlvm and you'll commit your patch as well as Tim's
clarification for GetSystemProperty.
Does it sound good to you?
--
Gregory
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni]
update for bootstrapClassPath causes regression on DRL VM)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
If that's all they are used for - the native interface to the same
thing, then fine.
But then write that down too in the comments that this is simply that...
geir
Alexey Varlamov wrote:
> 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>>
>> Alexey Varlamov wrote:
>> > 2006/12/13, Geir Magnusson Jr. <ge...@pobox.com>:
>> >>
>> >>
>> >> Gregory Shimansky wrote:
>> >> > Alexey Varlamov wrote:
>> >> >> 2006/12/13, Gregory Shimansky <gs...@gmail.com>:
>> >> >>> Tim Ellison wrote:
>> >> >>> > Alexey Varlamov wrote:
>> >> >>> >> Is there any reason to distinguish these cases? I suppose
>> no, then
>> >> >>> >> returned NULL is fine.
>> >> >>> >
>> >> >>> > Maybe we do, i.e. where there is no value "-Dfoobar". So
>> >> perhaps we
>> >> >>> > need to say that GetSystemProperty returns VMI_ERROR_NONE and
>> >> sets the
>> >> >>> > the *valuePtr to NULL if there is no value; and returns a
>> >> >>> > VMI_ERROR_NOT_FOUND if the property is undefined.
>> >> >>>
>> >> >>> Now I am confused. What is the difference between a property which
>> >> has
>> >> >>> no value and an undefined property?
>> >> >>
>> >> >> Some properties may act as a flag, e.g.
>> -Djava.lang.SecurityManager.
>> >> >> However, they have empty value in RI (interestingly, DRLVM ignores
>> >> >> such arguments - must be a bug). So NULL value is still enough to
>> >> >> indicate no such property is set.
>> >> >
>> >> > I don't see how we can distinguish such properties in drlvm using
>> just
>> >> > one function get_property(const char*, PropertyTable). It either
>> >> returns
>> >> > a valid pointer to the property string value or NULL.
>> >> >
>> >> > Also empty value in my understanding is still a valid value "".
>> >>
>> >> yes, but NULL and "" are still two different things. I suspect
>> that we
>> >> should simply modify the API to have return code :
>> >>
>> >> int status = get_property(const char* key, const char **value,
>> table)
>> >>
>> >> so you can see if the key exists if you care. You may not care.
>> >>
>> >> Or, add a new method
>> >>
>> >> int status = has_key(char *key);
>> >>
>> >> depending on whatever criterion we use for this API.
>> >
>> > There is such API:
>> > VMEXPORT int is_property_set(const char* key, PropertyTable
>> table_number);
>> > Actually, NULL property values are allowable in drlvm just
>> > historically, I see no strong reason to retain this.
>>
>> So we have it now, and you want to take it away because of it's
>> similarity to a Java API?
>
> The point is not a similarity per se, but consistency of the Java
> system properties and underlying VM properties. I may miss the point
> behind the VMI facilities for system properties, but in my
> understanding they are intended to backup Java properties. So this is
> a standard Java<>native communication.
>
>>
>> I'm not understanding yet what the harm is in having this facility.
>>
>> geir
>>
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni] update for bootstrapClassPath causes regression on DRL VM)
Posted by Alexey Varlamov <al...@gmail.com>.
2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Alexey Varlamov wrote:
> > 2006/12/13, Geir Magnusson Jr. <ge...@pobox.com>:
> >>
> >>
> >> Gregory Shimansky wrote:
> >> > Alexey Varlamov wrote:
> >> >> 2006/12/13, Gregory Shimansky <gs...@gmail.com>:
> >> >>> Tim Ellison wrote:
> >> >>> > Alexey Varlamov wrote:
> >> >>> >> Is there any reason to distinguish these cases? I suppose no, then
> >> >>> >> returned NULL is fine.
> >> >>> >
> >> >>> > Maybe we do, i.e. where there is no value "-Dfoobar". So
> >> perhaps we
> >> >>> > need to say that GetSystemProperty returns VMI_ERROR_NONE and
> >> sets the
> >> >>> > the *valuePtr to NULL if there is no value; and returns a
> >> >>> > VMI_ERROR_NOT_FOUND if the property is undefined.
> >> >>>
> >> >>> Now I am confused. What is the difference between a property which
> >> has
> >> >>> no value and an undefined property?
> >> >>
> >> >> Some properties may act as a flag, e.g. -Djava.lang.SecurityManager.
> >> >> However, they have empty value in RI (interestingly, DRLVM ignores
> >> >> such arguments - must be a bug). So NULL value is still enough to
> >> >> indicate no such property is set.
> >> >
> >> > I don't see how we can distinguish such properties in drlvm using just
> >> > one function get_property(const char*, PropertyTable). It either
> >> returns
> >> > a valid pointer to the property string value or NULL.
> >> >
> >> > Also empty value in my understanding is still a valid value "".
> >>
> >> yes, but NULL and "" are still two different things. I suspect that we
> >> should simply modify the API to have return code :
> >>
> >> int status = get_property(const char* key, const char **value, table)
> >>
> >> so you can see if the key exists if you care. You may not care.
> >>
> >> Or, add a new method
> >>
> >> int status = has_key(char *key);
> >>
> >> depending on whatever criterion we use for this API.
> >
> > There is such API:
> > VMEXPORT int is_property_set(const char* key, PropertyTable table_number);
> > Actually, NULL property values are allowable in drlvm just
> > historically, I see no strong reason to retain this.
>
> So we have it now, and you want to take it away because of it's
> similarity to a Java API?
The point is not a similarity per se, but consistency of the Java
system properties and underlying VM properties. I may miss the point
behind the VMI facilities for system properties, but in my
understanding they are intended to backup Java properties. So this is
a standard Java<>native communication.
>
> I'm not understanding yet what the harm is in having this facility.
>
> geir
>
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni]
update for bootstrapClassPath causes regression on DRL VM)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexey Varlamov wrote:
> 2006/12/13, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>>
>> Gregory Shimansky wrote:
>> > Alexey Varlamov wrote:
>> >> 2006/12/13, Gregory Shimansky <gs...@gmail.com>:
>> >>> Tim Ellison wrote:
>> >>> > Alexey Varlamov wrote:
>> >>> >> Is there any reason to distinguish these cases? I suppose no, then
>> >>> >> returned NULL is fine.
>> >>> >
>> >>> > Maybe we do, i.e. where there is no value "-Dfoobar". So
>> perhaps we
>> >>> > need to say that GetSystemProperty returns VMI_ERROR_NONE and
>> sets the
>> >>> > the *valuePtr to NULL if there is no value; and returns a
>> >>> > VMI_ERROR_NOT_FOUND if the property is undefined.
>> >>>
>> >>> Now I am confused. What is the difference between a property which
>> has
>> >>> no value and an undefined property?
>> >>
>> >> Some properties may act as a flag, e.g. -Djava.lang.SecurityManager.
>> >> However, they have empty value in RI (interestingly, DRLVM ignores
>> >> such arguments - must be a bug). So NULL value is still enough to
>> >> indicate no such property is set.
>> >
>> > I don't see how we can distinguish such properties in drlvm using just
>> > one function get_property(const char*, PropertyTable). It either
>> returns
>> > a valid pointer to the property string value or NULL.
>> >
>> > Also empty value in my understanding is still a valid value "".
>>
>> yes, but NULL and "" are still two different things. I suspect that we
>> should simply modify the API to have return code :
>>
>> int status = get_property(const char* key, const char **value, table)
>>
>> so you can see if the key exists if you care. You may not care.
>>
>> Or, add a new method
>>
>> int status = has_key(char *key);
>>
>> depending on whatever criterion we use for this API.
>
> There is such API:
> VMEXPORT int is_property_set(const char* key, PropertyTable table_number);
> Actually, NULL property values are allowable in drlvm just
> historically, I see no strong reason to retain this.
So we have it now, and you want to take it away because of it's
similarity to a Java API?
I'm not understanding yet what the harm is in having this facility.
geir
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni] update for bootstrapClassPath causes regression on DRL VM)
Posted by Alexey Varlamov <al...@gmail.com>.
2006/12/13, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Gregory Shimansky wrote:
> > Alexey Varlamov wrote:
> >> 2006/12/13, Gregory Shimansky <gs...@gmail.com>:
> >>> Tim Ellison wrote:
> >>> > Alexey Varlamov wrote:
> >>> >> Is there any reason to distinguish these cases? I suppose no, then
> >>> >> returned NULL is fine.
> >>> >
> >>> > Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
> >>> > need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
> >>> > the *valuePtr to NULL if there is no value; and returns a
> >>> > VMI_ERROR_NOT_FOUND if the property is undefined.
> >>>
> >>> Now I am confused. What is the difference between a property which has
> >>> no value and an undefined property?
> >>
> >> Some properties may act as a flag, e.g. -Djava.lang.SecurityManager.
> >> However, they have empty value in RI (interestingly, DRLVM ignores
> >> such arguments - must be a bug). So NULL value is still enough to
> >> indicate no such property is set.
> >
> > I don't see how we can distinguish such properties in drlvm using just
> > one function get_property(const char*, PropertyTable). It either returns
> > a valid pointer to the property string value or NULL.
> >
> > Also empty value in my understanding is still a valid value "".
>
> yes, but NULL and "" are still two different things. I suspect that we
> should simply modify the API to have return code :
>
> int status = get_property(const char* key, const char **value, table)
>
> so you can see if the key exists if you care. You may not care.
>
> Or, add a new method
>
> int status = has_key(char *key);
>
> depending on whatever criterion we use for this API.
There is such API:
VMEXPORT int is_property_set(const char* key, PropertyTable table_number);
Actually, NULL property values are allowable in drlvm just
historically, I see no strong reason to retain this.
>
> geir
>
> >
>
>
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni] update for bootstrapClassPath causes regression on DRL VM)
Posted by Alexey Varlamov <al...@gmail.com>.
2006/12/13, Gregory Shimansky <gs...@gmail.com>:
> Alexey Varlamov wrote:
> > 2006/12/13, Gregory Shimansky <gs...@gmail.com>:
> >> Tim Ellison wrote:
> >> > Alexey Varlamov wrote:
> >> >> Is there any reason to distinguish these cases? I suppose no, then
> >> >> returned NULL is fine.
> >> >
> >> > Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
> >> > need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
> >> > the *valuePtr to NULL if there is no value; and returns a
> >> > VMI_ERROR_NOT_FOUND if the property is undefined.
> >>
> >> Now I am confused. What is the difference between a property which has
> >> no value and an undefined property?
> >
> > Some properties may act as a flag, e.g. -Djava.lang.SecurityManager.
> > However, they have empty value in RI (interestingly, DRLVM ignores
> > such arguments - must be a bug). So NULL value is still enough to
> > indicate no such property is set.
>
> I don't see how we can distinguish such properties in drlvm using just
> one function get_property(const char*, PropertyTable). It either returns
> a valid pointer to the property string value or NULL.
Right, a special check with is_property_set() would be required.
> Also empty value in my understanding is still a valid value "".
This is correct. I believe we just need to document that NULL value is illegal.
> --
> Gregory
>
>
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni]
update for bootstrapClassPath causes regression on DRL VM)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> Alexey Varlamov wrote:
>> 2006/12/13, Gregory Shimansky <gs...@gmail.com>:
>>> Tim Ellison wrote:
>>> > Alexey Varlamov wrote:
>>> >> Is there any reason to distinguish these cases? I suppose no, then
>>> >> returned NULL is fine.
>>> >
>>> > Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
>>> > need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
>>> > the *valuePtr to NULL if there is no value; and returns a
>>> > VMI_ERROR_NOT_FOUND if the property is undefined.
>>>
>>> Now I am confused. What is the difference between a property which has
>>> no value and an undefined property?
>>
>> Some properties may act as a flag, e.g. -Djava.lang.SecurityManager.
>> However, they have empty value in RI (interestingly, DRLVM ignores
>> such arguments - must be a bug). So NULL value is still enough to
>> indicate no such property is set.
>
> I don't see how we can distinguish such properties in drlvm using just
> one function get_property(const char*, PropertyTable). It either returns
> a valid pointer to the property string value or NULL.
>
> Also empty value in my understanding is still a valid value "".
yes, but NULL and "" are still two different things. I suspect that we
should simply modify the API to have return code :
int status = get_property(const char* key, const char **value, table)
so you can see if the key exists if you care. You may not care.
Or, add a new method
int status = has_key(char *key);
depending on whatever criterion we use for this API.
geir
>
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni]
update for bootstrapClassPath causes regression on DRL VM)
Posted by Gregory Shimansky <gs...@gmail.com>.
Alexey Varlamov wrote:
> 2006/12/13, Gregory Shimansky <gs...@gmail.com>:
>> Tim Ellison wrote:
>> > Alexey Varlamov wrote:
>> >> Is there any reason to distinguish these cases? I suppose no, then
>> >> returned NULL is fine.
>> >
>> > Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
>> > need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
>> > the *valuePtr to NULL if there is no value; and returns a
>> > VMI_ERROR_NOT_FOUND if the property is undefined.
>>
>> Now I am confused. What is the difference between a property which has
>> no value and an undefined property?
>
> Some properties may act as a flag, e.g. -Djava.lang.SecurityManager.
> However, they have empty value in RI (interestingly, DRLVM ignores
> such arguments - must be a bug). So NULL value is still enough to
> indicate no such property is set.
I don't see how we can distinguish such properties in drlvm using just
one function get_property(const char*, PropertyTable). It either returns
a valid pointer to the property string value or NULL.
Also empty value in my understanding is still a valid value "".
--
Gregory
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni] update for bootstrapClassPath causes regression on DRL VM)
Posted by Alexey Varlamov <al...@gmail.com>.
2006/12/13, Gregory Shimansky <gs...@gmail.com>:
> Tim Ellison wrote:
> > Alexey Varlamov wrote:
> >> Is there any reason to distinguish these cases? I suppose no, then
> >> returned NULL is fine.
> >
> > Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
> > need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
> > the *valuePtr to NULL if there is no value; and returns a
> > VMI_ERROR_NOT_FOUND if the property is undefined.
>
> Now I am confused. What is the difference between a property which has
> no value and an undefined property?
Some properties may act as a flag, e.g. -Djava.lang.SecurityManager.
However, they have empty value in RI (interestingly, DRLVM ignores
such arguments - must be a bug). So NULL value is still enough to
indicate no such property is set.
>
> > You can also see if it is defined by using the IterateSystemProperties
> > to look for it.
> >
> > Index: luni/src/main/native/include/shared/vmi.h
> > ===================================================================
> > --- luni/src/main/native/include/shared/vmi.h (revision 486569)
> > +++ luni/src/main/native/include/shared/vmi.h (working copy)
> > @@ -220,7 +220,13 @@
> >
> > /**
> > * @fn VMInterfaceFunctions_::GetSystemProperty(VMInterface * vmi,
> > char *key, char **valuePtr)
> > - * Retrieve the value of a VM system property.
> > + * Retrieve the value of a VM system property.
> > + * If the property is not set this function returns
> > VMI_ERROR_NOT_FOUND and the value
> > + * of *valuePtr is undefined.
> > + * If the property is set, but has no value then the function returns
> > VMI_ERROR_NONE and
> > + * the *valuePtr will be NULL.
> > + * If the property is set and has a value then the function returns
> > VMI_ERROR_NONE and
> > + * the *valuePtr will be the address of the string value.
> > *
> > * @note The returned string is owned by the VM, and should not be freed.
> > */
> >
> >
> > Regards,
> > Tim
> >
>
>
> --
> Gregory
>
>
Re: [vmi] Retrieving system properties
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I agree with you 100%. I think the problem is that we aren't always
reacting to the CC messages.
As a good example of when things went right - when I broke the build
when I changed the structure of the deployed stuff in DRLVM
(lnx.../deploy/jdk...), Gregory told me onlist what he found, and I went
and did the fixes - immediate response, targetted fix...
geir
Mikhail Loenko wrote:
> I mean revert as few as possible changes (ideally one single commit)
> causing failure.
>
> 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
>> What do you want to roll back? Everything since that point in time?
>>
>> Mikhail Loenko wrote:
>> > +1 for rolling back the changes.
>> >
>> > We shoud aim 100% of up-time. If the build is working
>> > we can do further work, test and commit the changes, etc
>> >
>> > Let's roll it back so that other people who work on
>> > the project could continue
>> >
>> > Thanks,
>> > Mikhail
>> >
>> > 2006/12/14, Stepan Mishura <st...@gmail.com>:
>> >> On 12/14/06, Alexey Varlamov wrote:
>> >> >
>> >> > 2006/12/14, Tim Ellison :
>> >> > > Alexey Varlamov wrote:
>> >> > > > Fixed svn as agreed, both classlib and drlvm impl.
>> >> > >
>> >> > > Given it a VMI modification I would like to have had a more
>> >> coordinated
>> >> > > change, so the IBM VME can be changed too. We are also trying to
>> >> get a
>> >> > > snapshot out so this would be one I would defer until that is
>> done.
>> >> >
>> >> > AFAIU the snapshot is pointless if taken from broken repository
>> state.
>> >> > All CC systems were FAILED for > 2 days, since the initial
>> >> > modification which provoked this discussion. I presume it is
>> important
>> >> > enough to get back to PASSED status quickly.
>> >>
>> >>
>> >>
>> >> I support Alexey's point here.
>> >>
>> >> Sorry for being annoying but can not really understand what is the
>> >> problem
>> >> here with restoring things as they were before CC went down. And after
>> >> that we can work out an appropriate solution and coordinate a change
>> >> without
>> >> hurrying.
>> >>
>> >> Thanks,
>> >> Stepan.
>> >>
>> >> Besides my speculation
>> >> > was that current agreement reflects IBM VME behavior too so it does
>> >> > not require urgent update.
>> >> >
>> >> > >
>> >> > > Geir has some further questions on the rationale for the change.
>> >> Let's
>> >> > > give it more than 24hrs for agreement before committing.
>> >> > >
>> >> > > Regards,
>> >> > > Tim
>> >> > >
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Stepan Mishura
>> >> Intel Enterprise Solutions Software Division
>> >>
>> >>
>>
Re: [vmi] Retrieving system properties
Posted by Mikhail Loenko <ml...@gmail.com>.
I mean revert as few as possible changes (ideally one single commit)
causing failure.
2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
> What do you want to roll back? Everything since that point in time?
>
> Mikhail Loenko wrote:
> > +1 for rolling back the changes.
> >
> > We shoud aim 100% of up-time. If the build is working
> > we can do further work, test and commit the changes, etc
> >
> > Let's roll it back so that other people who work on
> > the project could continue
> >
> > Thanks,
> > Mikhail
> >
> > 2006/12/14, Stepan Mishura <st...@gmail.com>:
> >> On 12/14/06, Alexey Varlamov wrote:
> >> >
> >> > 2006/12/14, Tim Ellison :
> >> > > Alexey Varlamov wrote:
> >> > > > Fixed svn as agreed, both classlib and drlvm impl.
> >> > >
> >> > > Given it a VMI modification I would like to have had a more
> >> coordinated
> >> > > change, so the IBM VME can be changed too. We are also trying to
> >> get a
> >> > > snapshot out so this would be one I would defer until that is done.
> >> >
> >> > AFAIU the snapshot is pointless if taken from broken repository state.
> >> > All CC systems were FAILED for > 2 days, since the initial
> >> > modification which provoked this discussion. I presume it is important
> >> > enough to get back to PASSED status quickly.
> >>
> >>
> >>
> >> I support Alexey's point here.
> >>
> >> Sorry for being annoying but can not really understand what is the
> >> problem
> >> here with restoring things as they were before CC went down. And after
> >> that we can work out an appropriate solution and coordinate a change
> >> without
> >> hurrying.
> >>
> >> Thanks,
> >> Stepan.
> >>
> >> Besides my speculation
> >> > was that current agreement reflects IBM VME behavior too so it does
> >> > not require urgent update.
> >> >
> >> > >
> >> > > Geir has some further questions on the rationale for the change.
> >> Let's
> >> > > give it more than 24hrs for agreement before committing.
> >> > >
> >> > > Regards,
> >> > > Tim
> >> > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Stepan Mishura
> >> Intel Enterprise Solutions Software Division
> >>
> >>
>
Re: [vmi] Retrieving system properties
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
What do you want to roll back? Everything since that point in time?
Mikhail Loenko wrote:
> +1 for rolling back the changes.
>
> We shoud aim 100% of up-time. If the build is working
> we can do further work, test and commit the changes, etc
>
> Let's roll it back so that other people who work on
> the project could continue
>
> Thanks,
> Mikhail
>
> 2006/12/14, Stepan Mishura <st...@gmail.com>:
>> On 12/14/06, Alexey Varlamov wrote:
>> >
>> > 2006/12/14, Tim Ellison :
>> > > Alexey Varlamov wrote:
>> > > > Fixed svn as agreed, both classlib and drlvm impl.
>> > >
>> > > Given it a VMI modification I would like to have had a more
>> coordinated
>> > > change, so the IBM VME can be changed too. We are also trying to
>> get a
>> > > snapshot out so this would be one I would defer until that is done.
>> >
>> > AFAIU the snapshot is pointless if taken from broken repository state.
>> > All CC systems were FAILED for > 2 days, since the initial
>> > modification which provoked this discussion. I presume it is important
>> > enough to get back to PASSED status quickly.
>>
>>
>>
>> I support Alexey's point here.
>>
>> Sorry for being annoying but can not really understand what is the
>> problem
>> here with restoring things as they were before CC went down. And after
>> that we can work out an appropriate solution and coordinate a change
>> without
>> hurrying.
>>
>> Thanks,
>> Stepan.
>>
>> Besides my speculation
>> > was that current agreement reflects IBM VME behavior too so it does
>> > not require urgent update.
>> >
>> > >
>> > > Geir has some further questions on the rationale for the change.
>> Let's
>> > > give it more than 24hrs for agreement before committing.
>> > >
>> > > Regards,
>> > > Tim
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Stepan Mishura
>> Intel Enterprise Solutions Software Division
>>
>>
Re: [vmi] Retrieving system properties
Posted by Mikhail Loenko <ml...@gmail.com>.
+1 for rolling back the changes.
We shoud aim 100% of up-time. If the build is working
we can do further work, test and commit the changes, etc
Let's roll it back so that other people who work on
the project could continue
Thanks,
Mikhail
2006/12/14, Stepan Mishura <st...@gmail.com>:
> On 12/14/06, Alexey Varlamov wrote:
> >
> > 2006/12/14, Tim Ellison :
> > > Alexey Varlamov wrote:
> > > > Fixed svn as agreed, both classlib and drlvm impl.
> > >
> > > Given it a VMI modification I would like to have had a more coordinated
> > > change, so the IBM VME can be changed too. We are also trying to get a
> > > snapshot out so this would be one I would defer until that is done.
> >
> > AFAIU the snapshot is pointless if taken from broken repository state.
> > All CC systems were FAILED for > 2 days, since the initial
> > modification which provoked this discussion. I presume it is important
> > enough to get back to PASSED status quickly.
>
>
>
> I support Alexey's point here.
>
> Sorry for being annoying but can not really understand what is the problem
> here with restoring things as they were before CC went down. And after
> that we can work out an appropriate solution and coordinate a change without
> hurrying.
>
> Thanks,
> Stepan.
>
> Besides my speculation
> > was that current agreement reflects IBM VME behavior too so it does
> > not require urgent update.
> >
> > >
> > > Geir has some further questions on the rationale for the change. Let's
> > > give it more than 24hrs for agreement before committing.
> > >
> > > Regards,
> > > Tim
> > >
> > >
> >
>
>
>
> --
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>
>
Re: [vmi] Retrieving system properties
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Oliver Deakin wrote:
> Alexey Varlamov wrote:
>> 2006/12/15, Geir Magnusson Jr. <ge...@pobox.com>:
>>>
>>>
>>> Oliver Deakin wrote:
>>> <snip>
>>> It answers the question above, but didn't answer my earlier question (I
>>> think I asked, of why *not* to have (key, NULL)? The impl of
>>> System.getProperty() can enforce the API of System.getProperty(), but if
>>> we find it useful as a general facility in the VMI, why not?
>>
>> Well, IMO the equvalent question is: do we really find (key, NULL) so
>> useful that ready to bear inconvenience or ambiguity of mapping such
>> VMI properties to Java?
>
> Exactly what I was thinking. I guess we're looking at two different
> sides of the coin -
> Geir is thinking "why not have (key, NULL)?" and we are thinking "why have
> (key, NULL)?". To be honest, Im not sure there's a convincing argument
> on either
> side, since we have no actual example of a time when we may or may not want
> a NULL value for a key. So I veer slightly towards not having NULL
> values just
> to match the Java API (and avoid an extra check in System.getProperty())
> until
> we have a good reason to allow them.
In which case the addition of the thing will probably be way more
expensive...
Anyway, I give...
geir
>
> Regards,
> Oliver
>
>>
>>>
>>> The only reason I can think of is to avoid the extra NULL check (in
>>> Java), but you have to look at the result code anyway when using
>>> GetSystemProp(), right?
>>>
>>> geir
>>>
>>>
>>>
>>> >
>>> > Regards,
>>> > Oliver
>>> >
>>> >>
>>> >>
>>> >>>
>>> >>> Regards,
>>> >>> Oliver
>>> >>>
>>> >>> > geir
>>> >>> >
>>> >>>
>>> >>> --
>>> >>> Oliver Deakin
>>> >>> IBM United Kingdom Limited
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>>
>>
>
Re: [vmi] Retrieving system properties
Posted by Oliver Deakin <ol...@googlemail.com>.
Alexey Varlamov wrote:
> 2006/12/15, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>>
>> Oliver Deakin wrote:
>> <snip>
>> It answers the question above, but didn't answer my earlier question (I
>> think I asked, of why *not* to have (key, NULL)? The impl of
>> System.getProperty() can enforce the API of System.getProperty(), but if
>> we find it useful as a general facility in the VMI, why not?
>
> Well, IMO the equvalent question is: do we really find (key, NULL) so
> useful that ready to bear inconvenience or ambiguity of mapping such
> VMI properties to Java?
Exactly what I was thinking. I guess we're looking at two different
sides of the coin -
Geir is thinking "why not have (key, NULL)?" and we are thinking "why have
(key, NULL)?". To be honest, Im not sure there's a convincing argument
on either
side, since we have no actual example of a time when we may or may not want
a NULL value for a key. So I veer slightly towards not having NULL
values just
to match the Java API (and avoid an extra check in System.getProperty())
until
we have a good reason to allow them.
Regards,
Oliver
>
>>
>> The only reason I can think of is to avoid the extra NULL check (in
>> Java), but you have to look at the result code anyway when using
>> GetSystemProp(), right?
>>
>> geir
>>
>>
>>
>> >
>> > Regards,
>> > Oliver
>> >
>> >>
>> >>
>> >>>
>> >>> Regards,
>> >>> Oliver
>> >>>
>> >>> > geir
>> >>> >
>> >>>
>> >>> --
>> >>> Oliver Deakin
>> >>> IBM United Kingdom Limited
>> >>>
>> >>>
>> >>
>> >
>>
>>
>
--
Oliver Deakin
IBM United Kingdom Limited
Re: [vmi] Retrieving system properties
Posted by Alexey Varlamov <al...@gmail.com>.
2006/12/15, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Oliver Deakin wrote:
> > Alexey Varlamov wrote:
> >> 2006/12/14, Oliver Deakin <ol...@googlemail.com>:
> >>> Geir Magnusson Jr. wrote:
> >>> >
> >>> >
> >>> > Alexey Varlamov wrote:
> >>> >> 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
> >>> >>>
> >>> >>>
> >>> >>> Tim Ellison wrote:
> >>> >>> > Gregory Shimansky wrote:
> >>> >>> >> Tim Ellison wrote:
> >>> >>> >>> Gregory Shimansky wrote:
> >>> >>> >>>> Tim Ellison wrote:
> >>> >>> >>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So
> >>> >>> perhaps we
> >>> >>> >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and
> >>> >>> sets the
> >>> >>> >>>>> the *valuePtr to NULL if there is no value; and returns a
> >>> >>> >>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
> >>> >>> >>>> Now I am confused. What is the difference between a property
> >>> >>> which has
> >>> >>> >>>> no value and an undefined property?
> >>> >>> >>> Sorry, I meant a property whose value is NULL. So the three
> >>> >>> cases are:
> >>> >>> >>>
> >>> >>> >>> 1) key = "foo", value = "bar"
> >>> >>> >>> 2) key = "foo", value = NULL
> >>> >>> >>> 3) no key called "foo"
> >>> >>> >>>
> >>> >>> >>> If (2) is disallowed then we should document that in
> >>> >>> SetSystemProperty().
> >>> >>> >> I would prefer to have (2) to be illegal. Can we document this
> >>> >>> please?
> >>> >>> >
> >>> >>> > No objection here. So to attempt a new clarification ...
> >>> >>> >
> >>> >>> > GetSystemProperty will return VMI_ERROR_NONE and a string value
> >>> for
> >>> >>> > existing properties, or NULL value for a non-existent property.
> >>> >>> >
> >>> >>> > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
> >>> >>> > SetSystemProperty will return VMI_ERROR_NONE for setting an
> >>> existing
> >>> >>> > property to a string value, or VMI_ILLEGAL_ARG if there is an
> >>> >>> attempt to
> >>> >>> > set the property value to NULL.
> >>> >>> >
> >>> >>> > How does that sound?
> >>> >>>
> >>> >>> Why again do we want 2 to be illegal? (Sorry, was out of pocket
> >>> for a
> >>> >>> while there yesterday...)
> >>> >>
> >>> >> This is aligned with the API specification for
> >>> >> j.l.System.[s|g]etProperty(), which explicitly disallowes NULLs for
> >>> >> both keys and values.
> >>> >
> >>> > Why do I care about the Java API here?
> >>> >
> >>>
> >>> I think we need to here since we're talking about properties that are
> >>> accessible from Java. Do we want to be able to set a property that is
> >>> accessible from Java to a value that is invalid by the Java API? If
> >>> someone
> >>> calls System.getProperty() on a key that has NULL value, what do we
> >>> return?
> >>> Do we benefit from allowing NULL values?
> >>>
> >>> My personal feeling is that we should follow the Java API here, since
> >>> we're changing Java properties.
> >>
> >> Exactly! I said very same thing in parallel thread (BTW is it a bug of
> >> some mailer - reply going to a new thread with "Re:" ?).
> >>
> >
> > (Re: mailer bug - possibly, I see them split out of the thread as well,
> > but with
> > the correct "Re:" mail subject. Annoying because it breaks up the flow
> > of the
> > thread, and responses are easily missed/lost.)
> >
> >> So I believe we have true agreement here.
> >
> > Great! Geir, does this answer your question?
>
> It answers the question above, but didn't answer my earlier question (I
> think I asked, of why *not* to have (key, NULL)? The impl of
> System.getProperty() can enforce the API of System.getProperty(), but if
> we find it useful as a general facility in the VMI, why not?
Well, IMO the equvalent question is: do we really find (key, NULL) so
useful that ready to bear inconvenience or ambiguity of mapping such
VMI properties to Java?
>
> The only reason I can think of is to avoid the extra NULL check (in
> Java), but you have to look at the result code anyway when using
> GetSystemProp(), right?
>
> geir
>
>
>
> >
> > Regards,
> > Oliver
> >
> >>
> >>
> >>>
> >>> Regards,
> >>> Oliver
> >>>
> >>> > geir
> >>> >
> >>>
> >>> --
> >>> Oliver Deakin
> >>> IBM United Kingdom Limited
> >>>
> >>>
> >>
> >
>
>
Re: [vmi] Retrieving system properties
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Oliver Deakin wrote:
> Alexey Varlamov wrote:
>> 2006/12/14, Oliver Deakin <ol...@googlemail.com>:
>>> Geir Magnusson Jr. wrote:
>>> >
>>> >
>>> > Alexey Varlamov wrote:
>>> >> 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
>>> >>>
>>> >>>
>>> >>> Tim Ellison wrote:
>>> >>> > Gregory Shimansky wrote:
>>> >>> >> Tim Ellison wrote:
>>> >>> >>> Gregory Shimansky wrote:
>>> >>> >>>> Tim Ellison wrote:
>>> >>> >>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So
>>> >>> perhaps we
>>> >>> >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and
>>> >>> sets the
>>> >>> >>>>> the *valuePtr to NULL if there is no value; and returns a
>>> >>> >>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
>>> >>> >>>> Now I am confused. What is the difference between a property
>>> >>> which has
>>> >>> >>>> no value and an undefined property?
>>> >>> >>> Sorry, I meant a property whose value is NULL. So the three
>>> >>> cases are:
>>> >>> >>>
>>> >>> >>> 1) key = "foo", value = "bar"
>>> >>> >>> 2) key = "foo", value = NULL
>>> >>> >>> 3) no key called "foo"
>>> >>> >>>
>>> >>> >>> If (2) is disallowed then we should document that in
>>> >>> SetSystemProperty().
>>> >>> >> I would prefer to have (2) to be illegal. Can we document this
>>> >>> please?
>>> >>> >
>>> >>> > No objection here. So to attempt a new clarification ...
>>> >>> >
>>> >>> > GetSystemProperty will return VMI_ERROR_NONE and a string value
>>> for
>>> >>> > existing properties, or NULL value for a non-existent property.
>>> >>> >
>>> >>> > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
>>> >>> > SetSystemProperty will return VMI_ERROR_NONE for setting an
>>> existing
>>> >>> > property to a string value, or VMI_ILLEGAL_ARG if there is an
>>> >>> attempt to
>>> >>> > set the property value to NULL.
>>> >>> >
>>> >>> > How does that sound?
>>> >>>
>>> >>> Why again do we want 2 to be illegal? (Sorry, was out of pocket
>>> for a
>>> >>> while there yesterday...)
>>> >>
>>> >> This is aligned with the API specification for
>>> >> j.l.System.[s|g]etProperty(), which explicitly disallowes NULLs for
>>> >> both keys and values.
>>> >
>>> > Why do I care about the Java API here?
>>> >
>>>
>>> I think we need to here since we're talking about properties that are
>>> accessible from Java. Do we want to be able to set a property that is
>>> accessible from Java to a value that is invalid by the Java API? If
>>> someone
>>> calls System.getProperty() on a key that has NULL value, what do we
>>> return?
>>> Do we benefit from allowing NULL values?
>>>
>>> My personal feeling is that we should follow the Java API here, since
>>> we're changing Java properties.
>>
>> Exactly! I said very same thing in parallel thread (BTW is it a bug of
>> some mailer - reply going to a new thread with "Re:" ?).
>>
>
> (Re: mailer bug - possibly, I see them split out of the thread as well,
> but with
> the correct "Re:" mail subject. Annoying because it breaks up the flow
> of the
> thread, and responses are easily missed/lost.)
>
>> So I believe we have true agreement here.
>
> Great! Geir, does this answer your question?
It answers the question above, but didn't answer my earlier question (I
think I asked, of why *not* to have (key, NULL)? The impl of
System.getProperty() can enforce the API of System.getProperty(), but if
we find it useful as a general facility in the VMI, why not?
The only reason I can think of is to avoid the extra NULL check (in
Java), but you have to look at the result code anyway when using
GetSystemProp(), right?
geir
>
> Regards,
> Oliver
>
>>
>>
>>>
>>> Regards,
>>> Oliver
>>>
>>> > geir
>>> >
>>>
>>> --
>>> Oliver Deakin
>>> IBM United Kingdom Limited
>>>
>>>
>>
>
Re: [vmi] Retrieving system properties
Posted by Oliver Deakin <ol...@googlemail.com>.
Alexey Varlamov wrote:
> 2006/12/14, Oliver Deakin <ol...@googlemail.com>:
>> Geir Magnusson Jr. wrote:
>> >
>> >
>> > Alexey Varlamov wrote:
>> >> 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
>> >>>
>> >>>
>> >>> Tim Ellison wrote:
>> >>> > Gregory Shimansky wrote:
>> >>> >> Tim Ellison wrote:
>> >>> >>> Gregory Shimansky wrote:
>> >>> >>>> Tim Ellison wrote:
>> >>> >>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So
>> >>> perhaps we
>> >>> >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and
>> >>> sets the
>> >>> >>>>> the *valuePtr to NULL if there is no value; and returns a
>> >>> >>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
>> >>> >>>> Now I am confused. What is the difference between a property
>> >>> which has
>> >>> >>>> no value and an undefined property?
>> >>> >>> Sorry, I meant a property whose value is NULL. So the three
>> >>> cases are:
>> >>> >>>
>> >>> >>> 1) key = "foo", value = "bar"
>> >>> >>> 2) key = "foo", value = NULL
>> >>> >>> 3) no key called "foo"
>> >>> >>>
>> >>> >>> If (2) is disallowed then we should document that in
>> >>> SetSystemProperty().
>> >>> >> I would prefer to have (2) to be illegal. Can we document this
>> >>> please?
>> >>> >
>> >>> > No objection here. So to attempt a new clarification ...
>> >>> >
>> >>> > GetSystemProperty will return VMI_ERROR_NONE and a string value
>> for
>> >>> > existing properties, or NULL value for a non-existent property.
>> >>> >
>> >>> > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
>> >>> > SetSystemProperty will return VMI_ERROR_NONE for setting an
>> existing
>> >>> > property to a string value, or VMI_ILLEGAL_ARG if there is an
>> >>> attempt to
>> >>> > set the property value to NULL.
>> >>> >
>> >>> > How does that sound?
>> >>>
>> >>> Why again do we want 2 to be illegal? (Sorry, was out of pocket
>> for a
>> >>> while there yesterday...)
>> >>
>> >> This is aligned with the API specification for
>> >> j.l.System.[s|g]etProperty(), which explicitly disallowes NULLs for
>> >> both keys and values.
>> >
>> > Why do I care about the Java API here?
>> >
>>
>> I think we need to here since we're talking about properties that are
>> accessible from Java. Do we want to be able to set a property that is
>> accessible from Java to a value that is invalid by the Java API? If
>> someone
>> calls System.getProperty() on a key that has NULL value, what do we
>> return?
>> Do we benefit from allowing NULL values?
>>
>> My personal feeling is that we should follow the Java API here, since
>> we're changing Java properties.
>
> Exactly! I said very same thing in parallel thread (BTW is it a bug of
> some mailer - reply going to a new thread with "Re:" ?).
>
(Re: mailer bug - possibly, I see them split out of the thread as well,
but with
the correct "Re:" mail subject. Annoying because it breaks up the flow
of the
thread, and responses are easily missed/lost.)
> So I believe we have true agreement here.
Great! Geir, does this answer your question?
Regards,
Oliver
>
>
>>
>> Regards,
>> Oliver
>>
>> > geir
>> >
>>
>> --
>> Oliver Deakin
>> IBM United Kingdom Limited
>>
>>
>
--
Oliver Deakin
IBM United Kingdom Limited
Re: [vmi] Retrieving system properties
Posted by Alexey Varlamov <al...@gmail.com>.
2006/12/14, Oliver Deakin <ol...@googlemail.com>:
> Geir Magnusson Jr. wrote:
> >
> >
> > Alexey Varlamov wrote:
> >> 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
> >>>
> >>>
> >>> Tim Ellison wrote:
> >>> > Gregory Shimansky wrote:
> >>> >> Tim Ellison wrote:
> >>> >>> Gregory Shimansky wrote:
> >>> >>>> Tim Ellison wrote:
> >>> >>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So
> >>> perhaps we
> >>> >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and
> >>> sets the
> >>> >>>>> the *valuePtr to NULL if there is no value; and returns a
> >>> >>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
> >>> >>>> Now I am confused. What is the difference between a property
> >>> which has
> >>> >>>> no value and an undefined property?
> >>> >>> Sorry, I meant a property whose value is NULL. So the three
> >>> cases are:
> >>> >>>
> >>> >>> 1) key = "foo", value = "bar"
> >>> >>> 2) key = "foo", value = NULL
> >>> >>> 3) no key called "foo"
> >>> >>>
> >>> >>> If (2) is disallowed then we should document that in
> >>> SetSystemProperty().
> >>> >> I would prefer to have (2) to be illegal. Can we document this
> >>> please?
> >>> >
> >>> > No objection here. So to attempt a new clarification ...
> >>> >
> >>> > GetSystemProperty will return VMI_ERROR_NONE and a string value for
> >>> > existing properties, or NULL value for a non-existent property.
> >>> >
> >>> > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
> >>> > SetSystemProperty will return VMI_ERROR_NONE for setting an existing
> >>> > property to a string value, or VMI_ILLEGAL_ARG if there is an
> >>> attempt to
> >>> > set the property value to NULL.
> >>> >
> >>> > How does that sound?
> >>>
> >>> Why again do we want 2 to be illegal? (Sorry, was out of pocket for a
> >>> while there yesterday...)
> >>
> >> This is aligned with the API specification for
> >> j.l.System.[s|g]etProperty(), which explicitly disallowes NULLs for
> >> both keys and values.
> >
> > Why do I care about the Java API here?
> >
>
> I think we need to here since we're talking about properties that are
> accessible from Java. Do we want to be able to set a property that is
> accessible from Java to a value that is invalid by the Java API? If someone
> calls System.getProperty() on a key that has NULL value, what do we return?
> Do we benefit from allowing NULL values?
>
> My personal feeling is that we should follow the Java API here, since
> we're changing Java properties.
Exactly! I said very same thing in parallel thread (BTW is it a bug of
some mailer - reply going to a new thread with "Re:" ?).
So I believe we have true agreement here.
>
> Regards,
> Oliver
>
> > geir
> >
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
Re: [vmi] Retrieving system properties
Posted by Oliver Deakin <ol...@googlemail.com>.
Geir Magnusson Jr. wrote:
>
>
> Alexey Varlamov wrote:
>> 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
>>>
>>>
>>> Tim Ellison wrote:
>>> > Gregory Shimansky wrote:
>>> >> Tim Ellison wrote:
>>> >>> Gregory Shimansky wrote:
>>> >>>> Tim Ellison wrote:
>>> >>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So
>>> perhaps we
>>> >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and
>>> sets the
>>> >>>>> the *valuePtr to NULL if there is no value; and returns a
>>> >>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
>>> >>>> Now I am confused. What is the difference between a property
>>> which has
>>> >>>> no value and an undefined property?
>>> >>> Sorry, I meant a property whose value is NULL. So the three
>>> cases are:
>>> >>>
>>> >>> 1) key = "foo", value = "bar"
>>> >>> 2) key = "foo", value = NULL
>>> >>> 3) no key called "foo"
>>> >>>
>>> >>> If (2) is disallowed then we should document that in
>>> SetSystemProperty().
>>> >> I would prefer to have (2) to be illegal. Can we document this
>>> please?
>>> >
>>> > No objection here. So to attempt a new clarification ...
>>> >
>>> > GetSystemProperty will return VMI_ERROR_NONE and a string value for
>>> > existing properties, or NULL value for a non-existent property.
>>> >
>>> > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
>>> > SetSystemProperty will return VMI_ERROR_NONE for setting an existing
>>> > property to a string value, or VMI_ILLEGAL_ARG if there is an
>>> attempt to
>>> > set the property value to NULL.
>>> >
>>> > How does that sound?
>>>
>>> Why again do we want 2 to be illegal? (Sorry, was out of pocket for a
>>> while there yesterday...)
>>
>> This is aligned with the API specification for
>> j.l.System.[s|g]etProperty(), which explicitly disallowes NULLs for
>> both keys and values.
>
> Why do I care about the Java API here?
>
I think we need to here since we're talking about properties that are
accessible from Java. Do we want to be able to set a property that is
accessible from Java to a value that is invalid by the Java API? If someone
calls System.getProperty() on a key that has NULL value, what do we return?
Do we benefit from allowing NULL values?
My personal feeling is that we should follow the Java API here, since
we're changing Java properties.
Regards,
Oliver
> geir
>
--
Oliver Deakin
IBM United Kingdom Limited
Re: [vmi] Retrieving system properties
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexey Varlamov wrote:
> 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>>
>> Tim Ellison wrote:
>> > Gregory Shimansky wrote:
>> >> Tim Ellison wrote:
>> >>> Gregory Shimansky wrote:
>> >>>> Tim Ellison wrote:
>> >>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So
>> perhaps we
>> >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and
>> sets the
>> >>>>> the *valuePtr to NULL if there is no value; and returns a
>> >>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
>> >>>> Now I am confused. What is the difference between a property
>> which has
>> >>>> no value and an undefined property?
>> >>> Sorry, I meant a property whose value is NULL. So the three cases
>> are:
>> >>>
>> >>> 1) key = "foo", value = "bar"
>> >>> 2) key = "foo", value = NULL
>> >>> 3) no key called "foo"
>> >>>
>> >>> If (2) is disallowed then we should document that in
>> SetSystemProperty().
>> >> I would prefer to have (2) to be illegal. Can we document this please?
>> >
>> > No objection here. So to attempt a new clarification ...
>> >
>> > GetSystemProperty will return VMI_ERROR_NONE and a string value for
>> > existing properties, or NULL value for a non-existent property.
>> >
>> > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
>> > SetSystemProperty will return VMI_ERROR_NONE for setting an existing
>> > property to a string value, or VMI_ILLEGAL_ARG if there is an
>> attempt to
>> > set the property value to NULL.
>> >
>> > How does that sound?
>>
>> Why again do we want 2 to be illegal? (Sorry, was out of pocket for a
>> while there yesterday...)
>
> This is aligned with the API specification for
> j.l.System.[s|g]etProperty(), which explicitly disallowes NULLs for
> both keys and values.
Why do I care about the Java API here?
geir
Re: [vmi] Retrieving system properties
Posted by Alexey Varlamov <al...@gmail.com>.
2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Tim Ellison wrote:
> > Gregory Shimansky wrote:
> >> Tim Ellison wrote:
> >>> Gregory Shimansky wrote:
> >>>> Tim Ellison wrote:
> >>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
> >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
> >>>>> the *valuePtr to NULL if there is no value; and returns a
> >>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
> >>>> Now I am confused. What is the difference between a property which has
> >>>> no value and an undefined property?
> >>> Sorry, I meant a property whose value is NULL. So the three cases are:
> >>>
> >>> 1) key = "foo", value = "bar"
> >>> 2) key = "foo", value = NULL
> >>> 3) no key called "foo"
> >>>
> >>> If (2) is disallowed then we should document that in SetSystemProperty().
> >> I would prefer to have (2) to be illegal. Can we document this please?
> >
> > No objection here. So to attempt a new clarification ...
> >
> > GetSystemProperty will return VMI_ERROR_NONE and a string value for
> > existing properties, or NULL value for a non-existent property.
> >
> > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
> > SetSystemProperty will return VMI_ERROR_NONE for setting an existing
> > property to a string value, or VMI_ILLEGAL_ARG if there is an attempt to
> > set the property value to NULL.
> >
> > How does that sound?
>
> Why again do we want 2 to be illegal? (Sorry, was out of pocket for a
> while there yesterday...)
This is aligned with the API specification for
j.l.System.[s|g]etProperty(), which explicitly disallowes NULLs for
both keys and values.
>
> geir
>
>
Re: [vmi] Retrieving system properties
Posted by Stepan Mishura <st...@gmail.com>.
On 12/14/06, Geir Magnusson Jr. wrote:
>
>
>
> Stepan Mishura wrote:
> > On 12/14/06, Alexey Varlamov wrote:
> >>
> >> 2006/12/14, Tim Ellison :
> >> > Alexey Varlamov wrote:
> >> > > Fixed svn as agreed, both classlib and drlvm impl.
> >> >
> >> > Given it a VMI modification I would like to have had a more
> coordinated
> >> > change, so the IBM VME can be changed too. We are also trying to get
> a
> >> > snapshot out so this would be one I would defer until that is done.
> >>
> >> AFAIU the snapshot is pointless if taken from broken repository state.
> >> All CC systems were FAILED for > 2 days, since the initial
> >> modification which provoked this discussion. I presume it is important
> >> enough to get back to PASSED status quickly.
> >
> >
> >
> > I support Alexey's point here.
>
> I don't think that anyone is debating the goodness of getting things
> fixed. Thats clear. The problem is that the I still don't believe
> that the VMI thing was a fix, but rather a tweak to get rid of an
> ambiguity in the API.
>
> So... what was FAILING the CC?
Accoring to CC notifications CC failed after r486100. Vladimir (Ivanov) can
correct me if I'm wrong.
> >
> > Sorry for being annoying but can not really understand what is the
> problem
> > here with restoring things as they were before CC went down. And after
> > that we can work out an appropriate solution and coordinate a change
> > without
> > hurrying.
>
> I agree that things should be fixed ASAP, but I still think that we're
> confused about what the problem is. I don't agree that a massive
> rollback whenever we see a CC failure is the right thing to do, given
> the cascading problems that can create.
>
> Maybe an improvement in process is when there's a CC failure, someone
> investigate and simply report to the dev list what's going on. I think
> that's one of our problems right now... we're not engaging together on
> the CC problems...
I did investigation [1] but as I see now it wasn't enough to attract
attention to CC problems. So what should be done? Just roll back commit and
notify dev-list?
[1]
http://mail-archives.apache.org/mod_mbox/harmony-dev/200612.mbox/%3c6e47b64f0612122227p9371022h3e98701c8caf2d82@mail.gmail.com%3e
Thanks,
Stepan.
geir
>
>
> >
> > Thanks,
> > Stepan.
> >
> > Besides my speculation
> >> was that current agreement reflects IBM VME behavior too so it does
> >> not require urgent update.
> >>
> >> >
> >> > Geir has some further questions on the rationale for the
> change. Let's
> >> > give it more than 24hrs for agreement before committing.
> >> >
> >> > Regards,
> >> > Tim
> >> >
> >> >
> >>
> >
> >
> >
>
--
Stepan Mishura
Intel Enterprise Solutions Software Division
Re: [vmi] Retrieving system properties
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexey Varlamov wrote:
> 2006/12/14, Tim Ellison <t....@gmail.com>:
>> Alexey Varlamov wrote:
>> > Fixed svn as agreed, both classlib and drlvm impl.
>>
>> Given it a VMI modification I would like to have had a more coordinated
>> change, so the IBM VME can be changed too. We are also trying to get a
>> snapshot out so this would be one I would defer until that is done.
>
> AFAIU the snapshot is pointless if taken from broken repository state.
> All CC systems were FAILED for > 2 days, since the initial
> modification which provoked this discussion. I presume it is important
> enough to get back to PASSED status quickly. Besides my speculation
> was that current agreement reflects IBM VME behavior too so it does
> not require urgent update.
I didn't think it was a fix, but a clarification. I thought Gregory had
the fix in place already, and we were just polishing that nosecone.
geir
>
>>
>> Geir has some further questions on the rationale for the change. Let's
>> give it more than 24hrs for agreement before committing.
>>
>> Regards,
>> Tim
>>
>>
Re: [vmi] Retrieving system properties
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> 2006/12/14, Tim Ellison <t....@gmail.com>:
>> Alexey Varlamov wrote:
>> > Fixed svn as agreed, both classlib and drlvm impl.
>>
>> Given it a VMI modification I would like to have had a more coordinated
>> change, so the IBM VME can be changed too. We are also trying to get a
>> snapshot out so this would be one I would defer until that is done.
>
> AFAIU the snapshot is pointless if taken from broken repository state.
> All CC systems were FAILED for > 2 days, since the initial
> modification which provoked this discussion. I presume it is important
> enough to get back to PASSED status quickly. Besides my speculation
> was that current agreement reflects IBM VME behavior too so it does
> not require urgent update.
The IBM builds have been working ok for ages -- that test on the latest
classlib and IBM VME. There were some intermittent failures in Swing
tests recently that people are looking at, I don't think we all have to
stop while they do that. The recent SecurityManager test change caused
a trap, but that has been reverted so things are stable again afaik.
As mentioned elsewhere, there is already a workaround for getting the
system property for bootclasspath, and that is working ok for the
moment. I don't think there is any rush to get the VMI changes in place.
My understanding is that when committers are working in a module they
keep an eye open for subsequent test passes/failures. If the tests fail
then they will go and deal with it as they see fit. It seems to have
been working well like that so far.
I'm simply asking that the VMI changes wait for everyone to speak their
piece, the sable snapshot to be done, and a coordinated change to the
implementations effected.
Regards,
Tim
Re: [vmi] Retrieving system properties
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Stepan Mishura wrote:
> On 12/14/06, Alexey Varlamov wrote:
>>
>> 2006/12/14, Tim Ellison :
>> > Alexey Varlamov wrote:
>> > > Fixed svn as agreed, both classlib and drlvm impl.
>> >
>> > Given it a VMI modification I would like to have had a more coordinated
>> > change, so the IBM VME can be changed too. We are also trying to get a
>> > snapshot out so this would be one I would defer until that is done.
>>
>> AFAIU the snapshot is pointless if taken from broken repository state.
>> All CC systems were FAILED for > 2 days, since the initial
>> modification which provoked this discussion. I presume it is important
>> enough to get back to PASSED status quickly.
>
>
>
> I support Alexey's point here.
I don't think that anyone is debating the goodness of getting things
fixed. Thats clear. The problem is that the I still don't believe
that the VMI thing was a fix, but rather a tweak to get rid of an
ambiguity in the API.
So... what was FAILING the CC?
>
> Sorry for being annoying but can not really understand what is the problem
> here with restoring things as they were before CC went down. And after
> that we can work out an appropriate solution and coordinate a change
> without
> hurrying.
I agree that things should be fixed ASAP, but I still think that we're
confused about what the problem is. I don't agree that a massive
rollback whenever we see a CC failure is the right thing to do, given
the cascading problems that can create.
Maybe an improvement in process is when there's a CC failure, someone
investigate and simply report to the dev list what's going on. I think
that's one of our problems right now... we're not engaging together on
the CC problems...
geir
>
> Thanks,
> Stepan.
>
> Besides my speculation
>> was that current agreement reflects IBM VME behavior too so it does
>> not require urgent update.
>>
>> >
>> > Geir has some further questions on the rationale for the change. Let's
>> > give it more than 24hrs for agreement before committing.
>> >
>> > Regards,
>> > Tim
>> >
>> >
>>
>
>
>
Re: [vmi] Retrieving system properties
Posted by Stepan Mishura <st...@gmail.com>.
On 12/14/06, Alexey Varlamov wrote:
>
> 2006/12/14, Tim Ellison :
> > Alexey Varlamov wrote:
> > > Fixed svn as agreed, both classlib and drlvm impl.
> >
> > Given it a VMI modification I would like to have had a more coordinated
> > change, so the IBM VME can be changed too. We are also trying to get a
> > snapshot out so this would be one I would defer until that is done.
>
> AFAIU the snapshot is pointless if taken from broken repository state.
> All CC systems were FAILED for > 2 days, since the initial
> modification which provoked this discussion. I presume it is important
> enough to get back to PASSED status quickly.
I support Alexey's point here.
Sorry for being annoying but can not really understand what is the problem
here with restoring things as they were before CC went down. And after
that we can work out an appropriate solution and coordinate a change without
hurrying.
Thanks,
Stepan.
Besides my speculation
> was that current agreement reflects IBM VME behavior too so it does
> not require urgent update.
>
> >
> > Geir has some further questions on the rationale for the change. Let's
> > give it more than 24hrs for agreement before committing.
> >
> > Regards,
> > Tim
> >
> >
>
--
Stepan Mishura
Intel Enterprise Solutions Software Division
Re: [vmi] Retrieving system properties
Posted by Alexey Varlamov <al...@gmail.com>.
2006/12/14, Tim Ellison <t....@gmail.com>:
> Alexey Varlamov wrote:
> > Fixed svn as agreed, both classlib and drlvm impl.
>
> Given it a VMI modification I would like to have had a more coordinated
> change, so the IBM VME can be changed too. We are also trying to get a
> snapshot out so this would be one I would defer until that is done.
AFAIU the snapshot is pointless if taken from broken repository state.
All CC systems were FAILED for > 2 days, since the initial
modification which provoked this discussion. I presume it is important
enough to get back to PASSED status quickly. Besides my speculation
was that current agreement reflects IBM VME behavior too so it does
not require urgent update.
>
> Geir has some further questions on the rationale for the change. Let's
> give it more than 24hrs for agreement before committing.
>
> Regards,
> Tim
>
>
Re: [vmi] Retrieving system properties
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> Fixed svn as agreed, both classlib and drlvm impl.
Given it a VMI modification I would like to have had a more coordinated
change, so the IBM VME can be changed too. We are also trying to get a
snapshot out so this would be one I would defer until that is done.
Geir has some further questions on the rationale for the change. Let's
give it more than 24hrs for agreement before committing.
Regards,
Tim
Re: [vmi] Retrieving system properties
Posted by Alexey Varlamov <al...@gmail.com>.
Fixed svn as agreed, both classlib and drlvm impl.
The only minor issue remained, comment and code in the
modules\luni\src\main\native\luni\shared\luniglob.c:99 seems outdated
now:
/* Should we check if bootclasspath is already set to avoid
unexpected overriding? */
/* But this seems to conflict with default IBM VME settings...*/
/* (*vmInterface)->GetSystemProperty (vmInterface,
BOOTCLASSPATH_PROPERTY, &bootPath);*/
if (!bootPath)
<do readClassPathFromPropertiesFile>
I suppose we may drop it now.
--
Alexey
2006/12/13, Tim Ellison <t....@gmail.com>:
> yep, just need to fix the comment too
> > + VMI_ERROR_ILLEGAL_ARG = 5, /**< The requested system property was not found */
>
> Regards,
> Tim
>
> Oliver Deakin wrote:
> > Tim Ellison wrote:
> >> GetSystemProperty will return VMI_ERROR_NONE and a string value for
> >> existing properties, or NULL value for a non-existent property.
> >>
> >> We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
> >> SetSystemProperty will return VMI_ERROR_NONE for setting an existing
> >> property to a string value, or VMI_ILLEGAL_ARG if there is an attempt to
> >> set the property value to NULL.
> >>
> >> How does that sound?
> >>
> >
> > +1 to that - was writing the same thing but my machine blue screened :(
> > So I imagine the classlib patch would look something like:
> >
> > Index: modules/luni/src/main/native/include/shared/vmi.h
> > ===================================================================
> > --- modules/luni/src/main/native/include/shared/vmi.h (revision 486074)
> > +++ modules/luni/src/main/native/include/shared/vmi.h (working copy)
> > @@ -44,7 +44,7 @@
> > VMI_ERROR_UNIMPLEMENTED = 2, /**< Function has not been
> > implemented */
> > VMI_ERROR_UNSUPPORTED_VERSION = 3, /**< The requested VM interface
> > version is not supported */
> > VMI_ERROR_OUT_OF_MEMORY = 4, /**< Not enough memory was
> > available to complete the request */
> > - VMI_ERROR_NOT_FOUND = 5, /**< The requested system
> > property was not found */
> > + VMI_ERROR_ILLEGAL_ARG = 5, /**< The requested system
> > property was not found */
> > VMI_ERROR_READ_ONLY = 6, /**< An attempt was made to
> > modify a read-only item */
> > vmiErrorEnsureWideEnum = 0x1000000 /* ensure 4-byte enum */
> > } vmiError;
> > @@ -220,8 +220,13 @@
> >
> > /**
> > * @fn VMInterfaceFunctions_::GetSystemProperty(VMInterface * vmi, char
> > *key, char **valuePtr)
> > - * Retrieve the value of a VM system property.
> > + * Retrieve the value of a VM system property.
> > *
> > + * If the property exists, returns VMI_ERROR_NONE and *valuePtr
> > + * will be the address of the string value.
> > + * If the propery does not exist, returns VMI_ERROR_NONE and
> > + * *valuePtr will be NULL.
> > + *
> > * @note The returned string is owned by the VM, and should not be freed.
> > */
> > vmiError JNICALL GetSystemProperty (VMInterface * vmi, char *key,
> > @@ -230,7 +235,10 @@
> > /**
> > * @fn VMInterfaceFunctions_::SetSystemProperty(VMInterface * vmi, char
> > *key, char *value)
> > * Override the value of a VM system property
> > - *
> > + *
> > + * Returns VMI_ERROR_NONE if the property is set successfully.
> > + * Returns VMI_ERROR_ILLEGAL_ARG if value is NULL.
> > + *
> > * @code vmiError JNICALL SetSystemProperty(VMInterface* vmi, char* key,
> > char* value); @endcode
> > *
> > * @param[in] vmi The VM interface pointer
> > Index: modules/luni/src/main/native/luni/shared/luniglob.c
> > ===================================================================
> > --- modules/luni/src/main/native/luni/shared/luniglob.c (revision
> > 486569)
> > +++ modules/luni/src/main/native/luni/shared/luniglob.c (working copy)
> > @@ -269,14 +269,18 @@
> > /* Make a string version of the CP separator */
> > char cpSeparator[] = {(char)hysysinfo_get_classpathSeparator (),
> > '\0'};
> > - /* Read current value of bootclasspath property */
> > + /* Read current value of bootclasspath property - sets
> > + bootstrapClassPath = NULL if the property does not exist */
> > rcGetProperty = (*vmInterface)->GetSystemProperty (vmInterface,
> > BOOTCLASSPATH_PROPERTY,
> > &bootstrapClassPath);
> >
> > - /* Gregory - no property is found, VM bootclasspath is not
> > defined */
> > + /* There has been an error getting the property - cleanup and
> > exit */
> > if (VMI_ERROR_NONE != rcGetProperty)
> > - bootstrapClassPath = NULL;
> > + {
> > + returnCode = JNI_ERR;
> > + goto cleanup;
> > + }
> >
> > qsort(props, number, sizeof(key_value_pair), props_compare);
> >
> >
> > Regards,
> > Oliver
> >
> >> Tim
> >>
> >>
> >>
> >>
> >
>
Re: [vmi] Retrieving system properties
Posted by Alexey Varlamov <al...@gmail.com>.
+1
2006/12/13, Gregory Shimansky <gs...@gmail.com>:
> Tim Ellison wrote:
> > Gregory Shimansky wrote:
> >> Tim Ellison wrote:
> >>> Gregory Shimansky wrote:
> >>>> Tim Ellison wrote:
> >>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
> >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
> >>>>> the *valuePtr to NULL if there is no value; and returns a
> >>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
> >>>> Now I am confused. What is the difference between a property which has
> >>>> no value and an undefined property?
> >>> Sorry, I meant a property whose value is NULL. So the three cases are:
> >>>
> >>> 1) key = "foo", value = "bar"
> >>> 2) key = "foo", value = NULL
> >>> 3) no key called "foo"
> >>>
> >>> If (2) is disallowed then we should document that in SetSystemProperty().
> >> I would prefer to have (2) to be illegal. Can we document this please?
> >
> > No objection here. So to attempt a new clarification ...
> >
> > GetSystemProperty will return VMI_ERROR_NONE and a string value for
> > existing properties, or NULL value for a non-existent property.
> >
> > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
> > SetSystemProperty will return VMI_ERROR_NONE for setting an existing
> > property to a string value, or VMI_ILLEGAL_ARG if there is an attempt to
> > set the property value to NULL.
> >
> > How does that sound?
>
> I agree. +1 here. To fix drlvm VMI implementation only the following
> change is required:
>
> Index: vm/vmi/src/vmi.cpp
> ===================================================================
> --- vm/vmi/src/vmi.cpp (revision 486697)
> +++ vm/vmi/src/vmi.cpp (working copy)
> @@ -151,13 +151,11 @@
> {
> *valuePtr = strdup(value);
> destroy_property_value(value);
> - return VMI_ERROR_NONE;
> }
> else
> - {
> *valuePtr = NULL;
> - return VMI_ERROR_NOT_FOUND;
> - }
> +
> + return VMI_ERROR_NONE;
> }
>
> vmiError JNICALL
>
> --
> Gregory
>
>
Re: [vmi] Retrieving system properties
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Gregory Shimansky wrote:
>> Tim Ellison wrote:
>>> Gregory Shimansky wrote:
>>>> Tim Ellison wrote:
>>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
>>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
>>>>> the *valuePtr to NULL if there is no value; and returns a
>>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
>>>> Now I am confused. What is the difference between a property which has
>>>> no value and an undefined property?
>>> Sorry, I meant a property whose value is NULL. So the three cases are:
>>>
>>> 1) key = "foo", value = "bar"
>>> 2) key = "foo", value = NULL
>>> 3) no key called "foo"
>>>
>>> If (2) is disallowed then we should document that in SetSystemProperty().
>> I would prefer to have (2) to be illegal. Can we document this please?
>
> No objection here. So to attempt a new clarification ...
>
> GetSystemProperty will return VMI_ERROR_NONE and a string value for
> existing properties, or NULL value for a non-existent property.
>
> We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
> SetSystemProperty will return VMI_ERROR_NONE for setting an existing
> property to a string value, or VMI_ILLEGAL_ARG if there is an attempt to
> set the property value to NULL.
>
> How does that sound?
Why again do we want 2 to be illegal? (Sorry, was out of pocket for a
while there yesterday...)
geir
Re: [vmi] Retrieving system properties
Posted by Gregory Shimansky <gs...@gmail.com>.
Tim Ellison wrote:
> Gregory Shimansky wrote:
>> Tim Ellison wrote:
>>> Gregory Shimansky wrote:
>>>> Tim Ellison wrote:
>>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
>>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
>>>>> the *valuePtr to NULL if there is no value; and returns a
>>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
>>>> Now I am confused. What is the difference between a property which has
>>>> no value and an undefined property?
>>> Sorry, I meant a property whose value is NULL. So the three cases are:
>>>
>>> 1) key = "foo", value = "bar"
>>> 2) key = "foo", value = NULL
>>> 3) no key called "foo"
>>>
>>> If (2) is disallowed then we should document that in SetSystemProperty().
>> I would prefer to have (2) to be illegal. Can we document this please?
>
> No objection here. So to attempt a new clarification ...
>
> GetSystemProperty will return VMI_ERROR_NONE and a string value for
> existing properties, or NULL value for a non-existent property.
>
> We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
> SetSystemProperty will return VMI_ERROR_NONE for setting an existing
> property to a string value, or VMI_ILLEGAL_ARG if there is an attempt to
> set the property value to NULL.
>
> How does that sound?
I agree. +1 here. To fix drlvm VMI implementation only the following
change is required:
Index: vm/vmi/src/vmi.cpp
===================================================================
--- vm/vmi/src/vmi.cpp (revision 486697)
+++ vm/vmi/src/vmi.cpp (working copy)
@@ -151,13 +151,11 @@
{
*valuePtr = strdup(value);
destroy_property_value(value);
- return VMI_ERROR_NONE;
}
else
- {
*valuePtr = NULL;
- return VMI_ERROR_NOT_FOUND;
- }
+
+ return VMI_ERROR_NONE;
}
vmiError JNICALL
--
Gregory
Re: [vmi] Retrieving system properties
Posted by Tim Ellison <t....@gmail.com>.
yep, just need to fix the comment too
> + VMI_ERROR_ILLEGAL_ARG = 5, /**< The requested system property was not found */
Regards,
Tim
Oliver Deakin wrote:
> Tim Ellison wrote:
>> GetSystemProperty will return VMI_ERROR_NONE and a string value for
>> existing properties, or NULL value for a non-existent property.
>>
>> We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
>> SetSystemProperty will return VMI_ERROR_NONE for setting an existing
>> property to a string value, or VMI_ILLEGAL_ARG if there is an attempt to
>> set the property value to NULL.
>>
>> How does that sound?
>>
>
> +1 to that - was writing the same thing but my machine blue screened :(
> So I imagine the classlib patch would look something like:
>
> Index: modules/luni/src/main/native/include/shared/vmi.h
> ===================================================================
> --- modules/luni/src/main/native/include/shared/vmi.h (revision 486074)
> +++ modules/luni/src/main/native/include/shared/vmi.h (working copy)
> @@ -44,7 +44,7 @@
> VMI_ERROR_UNIMPLEMENTED = 2, /**< Function has not been
> implemented */
> VMI_ERROR_UNSUPPORTED_VERSION = 3, /**< The requested VM interface
> version is not supported */
> VMI_ERROR_OUT_OF_MEMORY = 4, /**< Not enough memory was
> available to complete the request */
> - VMI_ERROR_NOT_FOUND = 5, /**< The requested system
> property was not found */
> + VMI_ERROR_ILLEGAL_ARG = 5, /**< The requested system
> property was not found */
> VMI_ERROR_READ_ONLY = 6, /**< An attempt was made to
> modify a read-only item */
> vmiErrorEnsureWideEnum = 0x1000000 /* ensure 4-byte enum */
> } vmiError;
> @@ -220,8 +220,13 @@
>
> /**
> * @fn VMInterfaceFunctions_::GetSystemProperty(VMInterface * vmi, char
> *key, char **valuePtr)
> - * Retrieve the value of a VM system property.
> + * Retrieve the value of a VM system property.
> *
> + * If the property exists, returns VMI_ERROR_NONE and *valuePtr
> + * will be the address of the string value.
> + * If the propery does not exist, returns VMI_ERROR_NONE and
> + * *valuePtr will be NULL.
> + *
> * @note The returned string is owned by the VM, and should not be freed.
> */
> vmiError JNICALL GetSystemProperty (VMInterface * vmi, char *key,
> @@ -230,7 +235,10 @@
> /**
> * @fn VMInterfaceFunctions_::SetSystemProperty(VMInterface * vmi, char
> *key, char *value)
> * Override the value of a VM system property
> - *
> + *
> + * Returns VMI_ERROR_NONE if the property is set successfully.
> + * Returns VMI_ERROR_ILLEGAL_ARG if value is NULL.
> + *
> * @code vmiError JNICALL SetSystemProperty(VMInterface* vmi, char* key,
> char* value); @endcode
> *
> * @param[in] vmi The VM interface pointer
> Index: modules/luni/src/main/native/luni/shared/luniglob.c
> ===================================================================
> --- modules/luni/src/main/native/luni/shared/luniglob.c (revision
> 486569)
> +++ modules/luni/src/main/native/luni/shared/luniglob.c (working copy)
> @@ -269,14 +269,18 @@
> /* Make a string version of the CP separator */
> char cpSeparator[] = {(char)hysysinfo_get_classpathSeparator (),
> '\0'};
> - /* Read current value of bootclasspath property */
> + /* Read current value of bootclasspath property - sets
> + bootstrapClassPath = NULL if the property does not exist */
> rcGetProperty = (*vmInterface)->GetSystemProperty (vmInterface,
> BOOTCLASSPATH_PROPERTY,
> &bootstrapClassPath);
>
> - /* Gregory - no property is found, VM bootclasspath is not
> defined */
> + /* There has been an error getting the property - cleanup and
> exit */
> if (VMI_ERROR_NONE != rcGetProperty)
> - bootstrapClassPath = NULL;
> + {
> + returnCode = JNI_ERR;
> + goto cleanup;
> + }
>
> qsort(props, number, sizeof(key_value_pair), props_compare);
>
>
> Regards,
> Oliver
>
>> Tim
>>
>>
>>
>>
>
Re: [vmi] Retrieving system properties
Posted by Oliver Deakin <ol...@googlemail.com>.
Tim Ellison wrote:
> GetSystemProperty will return VMI_ERROR_NONE and a string value for
> existing properties, or NULL value for a non-existent property.
>
> We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
> SetSystemProperty will return VMI_ERROR_NONE for setting an existing
> property to a string value, or VMI_ILLEGAL_ARG if there is an attempt to
> set the property value to NULL.
>
> How does that sound?
>
+1 to that - was writing the same thing but my machine blue screened :(
So I imagine the classlib patch would look something like:
Index: modules/luni/src/main/native/include/shared/vmi.h
===================================================================
--- modules/luni/src/main/native/include/shared/vmi.h (revision 486074)
+++ modules/luni/src/main/native/include/shared/vmi.h (working copy)
@@ -44,7 +44,7 @@
VMI_ERROR_UNIMPLEMENTED = 2, /**< Function has not been
implemented */
VMI_ERROR_UNSUPPORTED_VERSION = 3, /**< The requested VM interface
version is not supported */
VMI_ERROR_OUT_OF_MEMORY = 4, /**< Not enough memory was
available to complete the request */
- VMI_ERROR_NOT_FOUND = 5, /**< The requested system
property was not found */
+ VMI_ERROR_ILLEGAL_ARG = 5, /**< The requested system
property was not found */
VMI_ERROR_READ_ONLY = 6, /**< An attempt was made to
modify a read-only item */
vmiErrorEnsureWideEnum = 0x1000000 /* ensure 4-byte enum */
} vmiError;
@@ -220,8 +220,13 @@
/**
* @fn VMInterfaceFunctions_::GetSystemProperty(VMInterface * vmi,
char *key, char **valuePtr)
- * Retrieve the value of a VM system property.
+ * Retrieve the value of a VM system property.
*
+ * If the property exists, returns VMI_ERROR_NONE and *valuePtr
+ * will be the address of the string value.
+ * If the propery does not exist, returns VMI_ERROR_NONE and
+ * *valuePtr will be NULL.
+ *
* @note The returned string is owned by the VM, and should not be freed.
*/
vmiError JNICALL GetSystemProperty (VMInterface * vmi, char *key,
@@ -230,7 +235,10 @@
/**
* @fn VMInterfaceFunctions_::SetSystemProperty(VMInterface * vmi, char
*key, char *value)
* Override the value of a VM system property
- *
+ *
+ * Returns VMI_ERROR_NONE if the property is set successfully.
+ * Returns VMI_ERROR_ILLEGAL_ARG if value is NULL.
+ *
* @code vmiError JNICALL SetSystemProperty(VMInterface* vmi, char*
key, char* value); @endcode
*
* @param[in] vmi The VM interface pointer
Index: modules/luni/src/main/native/luni/shared/luniglob.c
===================================================================
--- modules/luni/src/main/native/luni/shared/luniglob.c (revision 486569)
+++ modules/luni/src/main/native/luni/shared/luniglob.c (working copy)
@@ -269,14 +269,18 @@
/* Make a string version of the CP separator */
char cpSeparator[] = {(char)hysysinfo_get_classpathSeparator
(), '\0'};
- /* Read current value of bootclasspath property */
+ /* Read current value of bootclasspath property - sets
+ bootstrapClassPath = NULL if the property does not exist */
rcGetProperty = (*vmInterface)->GetSystemProperty (vmInterface,
BOOTCLASSPATH_PROPERTY,
&bootstrapClassPath);
- /* Gregory - no property is found, VM bootclasspath is not
defined */
+ /* There has been an error getting the property - cleanup and
exit */
if (VMI_ERROR_NONE != rcGetProperty)
- bootstrapClassPath = NULL;
+ {
+ returnCode = JNI_ERR;
+ goto cleanup;
+ }
qsort(props, number, sizeof(key_value_pair), props_compare);
Regards,
Oliver
> Tim
>
>
>
>
--
Oliver Deakin
IBM United Kingdom Limited
Re: [vmi] Retrieving system properties
Posted by Tim Ellison <t....@gmail.com>.
Gregory Shimansky wrote:
> Tim Ellison wrote:
>> Gregory Shimansky wrote:
>>> Tim Ellison wrote:
>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
>>>> the *valuePtr to NULL if there is no value; and returns a
>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
>>> Now I am confused. What is the difference between a property which has
>>> no value and an undefined property?
>>
>> Sorry, I meant a property whose value is NULL. So the three cases are:
>>
>> 1) key = "foo", value = "bar"
>> 2) key = "foo", value = NULL
>> 3) no key called "foo"
>>
>> If (2) is disallowed then we should document that in SetSystemProperty().
>
> I would prefer to have (2) to be illegal. Can we document this please?
No objection here. So to attempt a new clarification ...
GetSystemProperty will return VMI_ERROR_NONE and a string value for
existing properties, or NULL value for a non-existent property.
We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
SetSystemProperty will return VMI_ERROR_NONE for setting an existing
property to a string value, or VMI_ILLEGAL_ARG if there is an attempt to
set the property value to NULL.
How does that sound?
Tim
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni]
update for bootstrapClassPath causes regression on DRL VM)
Posted by Gregory Shimansky <gs...@gmail.com>.
Geir Magnusson Jr. wrote:
>
>
> Gregory Shimansky wrote:
>> Tim Ellison wrote:
>>> Gregory Shimansky wrote:
>>>> Tim Ellison wrote:
>>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
>>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
>>>>> the *valuePtr to NULL if there is no value; and returns a
>>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
>>>> Now I am confused. What is the difference between a property which has
>>>> no value and an undefined property?
>>>
>>> Sorry, I meant a property whose value is NULL. So the three cases are:
>>>
>>> 1) key = "foo", value = "bar"
>>> 2) key = "foo", value = NULL
>>> 3) no key called "foo"
>>>
>>> If (2) is disallowed then we should document that in
>>> SetSystemProperty().
>>
>> I would prefer to have (2) to be illegal. Can we document this please?
>
> Why would 2 be illegal?
Just adding to what other people wrote in this thread, I don't see a
real usecase to invent our own concept of properties different from Java
concept. It will just make the understanding harder for no apparent reason.
--
Gregory
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni]
update for bootstrapClassPath causes regression on DRL VM)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> Tim Ellison wrote:
>> Gregory Shimansky wrote:
>>> Tim Ellison wrote:
>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
>>>> the *valuePtr to NULL if there is no value; and returns a
>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
>>> Now I am confused. What is the difference between a property which has
>>> no value and an undefined property?
>>
>> Sorry, I meant a property whose value is NULL. So the three cases are:
>>
>> 1) key = "foo", value = "bar"
>> 2) key = "foo", value = NULL
>> 3) no key called "foo"
>>
>> If (2) is disallowed then we should document that in SetSystemProperty().
>
> I would prefer to have (2) to be illegal. Can we document this please?
Why would 2 be illegal?
geir
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni]
update for bootstrapClassPath causes regression on DRL VM)
Posted by Gregory Shimansky <gs...@gmail.com>.
Tim Ellison wrote:
> Gregory Shimansky wrote:
>> Tim Ellison wrote:
>>> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
>>> the *valuePtr to NULL if there is no value; and returns a
>>> VMI_ERROR_NOT_FOUND if the property is undefined.
>> Now I am confused. What is the difference between a property which has
>> no value and an undefined property?
>
> Sorry, I meant a property whose value is NULL. So the three cases are:
>
> 1) key = "foo", value = "bar"
> 2) key = "foo", value = NULL
> 3) no key called "foo"
>
> If (2) is disallowed then we should document that in SetSystemProperty().
I would prefer to have (2) to be illegal. Can we document this please?
--
Gregory
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni]
update for bootstrapClassPath causes regression on DRL VM)
Posted by Tim Ellison <t....@gmail.com>.
Gregory Shimansky wrote:
> Tim Ellison wrote:
>> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
>> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
>> the *valuePtr to NULL if there is no value; and returns a
>> VMI_ERROR_NOT_FOUND if the property is undefined.
>
> Now I am confused. What is the difference between a property which has
> no value and an undefined property?
Sorry, I meant a property whose value is NULL. So the three cases are:
1) key = "foo", value = "bar"
2) key = "foo", value = NULL
3) no key called "foo"
If (2) is disallowed then we should document that in SetSystemProperty().
Regards,
Tim
Re: [vmi] Retrieving system properties (was: Re: [classlib][luni]
update for bootstrapClassPath causes regression on DRL VM)
Posted by Gregory Shimansky <gs...@gmail.com>.
Tim Ellison wrote:
> Alexey Varlamov wrote:
>> Is there any reason to distinguish these cases? I suppose no, then
>> returned NULL is fine.
>
> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
> the *valuePtr to NULL if there is no value; and returns a
> VMI_ERROR_NOT_FOUND if the property is undefined.
Now I am confused. What is the difference between a property which has
no value and an undefined property?
> You can also see if it is defined by using the IterateSystemProperties
> to look for it.
>
> Index: luni/src/main/native/include/shared/vmi.h
> ===================================================================
> --- luni/src/main/native/include/shared/vmi.h (revision 486569)
> +++ luni/src/main/native/include/shared/vmi.h (working copy)
> @@ -220,7 +220,13 @@
>
> /**
> * @fn VMInterfaceFunctions_::GetSystemProperty(VMInterface * vmi,
> char *key, char **valuePtr)
> - * Retrieve the value of a VM system property.
> + * Retrieve the value of a VM system property.
> + * If the property is not set this function returns
> VMI_ERROR_NOT_FOUND and the value
> + * of *valuePtr is undefined.
> + * If the property is set, but has no value then the function returns
> VMI_ERROR_NONE and
> + * the *valuePtr will be NULL.
> + * If the property is set and has a value then the function returns
> VMI_ERROR_NONE and
> + * the *valuePtr will be the address of the string value.
> *
> * @note The returned string is owned by the VM, and should not be freed.
> */
>
>
> Regards,
> Tim
>
--
Gregory
[vmi] Retrieving system properties (was: Re: [classlib][luni] update
for bootstrapClassPath causes regression on DRL VM)
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> Is there any reason to distinguish these cases? I suppose no, then
> returned NULL is fine.
Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we
need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the
the *valuePtr to NULL if there is no value; and returns a
VMI_ERROR_NOT_FOUND if the property is undefined.
You can also see if it is defined by using the IterateSystemProperties
to look for it.
Index: luni/src/main/native/include/shared/vmi.h
===================================================================
--- luni/src/main/native/include/shared/vmi.h (revision 486569)
+++ luni/src/main/native/include/shared/vmi.h (working copy)
@@ -220,7 +220,13 @@
/**
* @fn VMInterfaceFunctions_::GetSystemProperty(VMInterface * vmi,
char *key, char **valuePtr)
- * Retrieve the value of a VM system property.
+ * Retrieve the value of a VM system property.
+ * If the property is not set this function returns
VMI_ERROR_NOT_FOUND and the value
+ * of *valuePtr is undefined.
+ * If the property is set, but has no value then the function returns
VMI_ERROR_NONE and
+ * the *valuePtr will be NULL.
+ * If the property is set and has a value then the function returns
VMI_ERROR_NONE and
+ * the *valuePtr will be the address of the string value.
*
* @note The returned string is owned by the VM, and should not be freed.
*/
Regards,
Tim
Re: [classlib][luni] update for bootstrapClassPath causes regression on DRL VM
Posted by Alexey Varlamov <al...@gmail.com>.
2006/12/13, Oliver Deakin <ol...@googlemail.com>:
> Tim Ellison wrote:
> > Geir Magnusson Jr. wrote:
> >
> >> Do we really have a problem? Or is it something else?
> >>
> >> Last night, Gregory tested his fix, and I've build snapshots (r486417)
> >> on x86 linux/win and x86_64 linux and spot checked with apps and such,
> >> and things seem to work.
> >>
> >> I'n posting the snapshots now to ~geirm and will send a separate note
> >> for people to evaluate.
> >>
> >
> > Also catching up on mail. I suggested (on the other thread) that we
> > need to define the return result for undefined properties, answering
> > NULL seemed reasonable, but now I look at the vmiError enum in vmi.h it
> > appears that we have already defined:
> > "VMI_ERROR_NOT_FOUND -- The requested system property was not found"
> >
> >
>
> This surprises me slightly - I would have imagined we would want to work
> in a similar way
> to the System.getSystem() method and return NULL in the case of a
> non-existent property
> being requested. However, it appears that GetSystemProperty() is
> intended to return
> VMI_ERROR_NOT_FOUND in this case.
>
> I would say that since the function behaviour in this case has not yet
> been clearly spec'ed
> (and we have two VMs that behave differently) we should make a choice
> now about which
> return is correct and fix up the VMs. So, should we just return a NULL
> property value and
> no error code, or return VMI_ERROR_NOT_FOUND?
Is there any reason to distinguish these cases? I suppose no, then
returned NULL is fine.
--
Alexey
>
> Regards,
> Oliver
>
>
> > Regards,
> > Tim
> >
> >
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
Re: [classlib][luni] update for bootstrapClassPath causes regression
on DRL VM
Posted by Oliver Deakin <ol...@googlemail.com>.
Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>
>> Do we really have a problem? Or is it something else?
>>
>> Last night, Gregory tested his fix, and I've build snapshots (r486417)
>> on x86 linux/win and x86_64 linux and spot checked with apps and such,
>> and things seem to work.
>>
>> I'n posting the snapshots now to ~geirm and will send a separate note
>> for people to evaluate.
>>
>
> Also catching up on mail. I suggested (on the other thread) that we
> need to define the return result for undefined properties, answering
> NULL seemed reasonable, but now I look at the vmiError enum in vmi.h it
> appears that we have already defined:
> "VMI_ERROR_NOT_FOUND -- The requested system property was not found"
>
>
This surprises me slightly - I would have imagined we would want to work
in a similar way
to the System.getSystem() method and return NULL in the case of a
non-existent property
being requested. However, it appears that GetSystemProperty() is
intended to return
VMI_ERROR_NOT_FOUND in this case.
I would say that since the function behaviour in this case has not yet
been clearly spec'ed
(and we have two VMs that behave differently) we should make a choice
now about which
return is correct and fix up the VMs. So, should we just return a NULL
property value and
no error code, or return VMI_ERROR_NOT_FOUND?
Regards,
Oliver
> Regards,
> Tim
>
>
--
Oliver Deakin
IBM United Kingdom Limited
Re: [classlib][luni] update for bootstrapClassPath causes regression
on DRL VM
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Do we really have a problem? Or is it something else?
>
> Last night, Gregory tested his fix, and I've build snapshots (r486417)
> on x86 linux/win and x86_64 linux and spot checked with apps and such,
> and things seem to work.
>
> I'n posting the snapshots now to ~geirm and will send a separate note
> for people to evaluate.
Also catching up on mail. I suggested (on the other thread) that we
need to define the return result for undefined properties, answering
NULL seemed reasonable, but now I look at the vmiError enum in vmi.h it
appears that we have already defined:
"VMI_ERROR_NOT_FOUND -- The requested system property was not found"
Regards,
Tim
Re: [classlib][luni] update for bootstrapClassPath causes regression
on DRL VM (was: Re: [drlvm][classlib] CC is failed to run classlib tests
over the DRLVM)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Do we really have a problem? Or is it something else?
Last night, Gregory tested his fix, and I've build snapshots (r486417)
on x86 linux/win and x86_64 linux and spot checked with apps and such,
and things seem to work.
I'n posting the snapshots now to ~geirm and will send a separate note
for people to evaluate.
geir
Stepan Mishura wrote:
> On 12/13/06, Geir Magnusson Jr. wrote:
>>
>> Grrr. We had a thread last night "DRLVM broken on em64t" that you
>> should read.
>
>
> Sorry, I hadn't read the discussion when I wrote about regression.
>
> In the end, what I was asking is if/how the behavior of
>> GetSystemProperty() changed with our update to the property management
>> inside of DRLVM, and the ramifications of that.
>>
>> Looking at Ollie's change in r486100, he seems to think that it's not an
>> error to not have the property set, but our impl of GetSystemProperty it
>> is.
>>
>> That's the issue I'm trying to get to - does the API of
>> GetSystemProperty() specify that it returns an error code if the
>> property isn't set?
>>
>> If so, then Ollie's code is wrong. If not, then it's either that the
>> API is ambiguous (Ollie's assumption wasn't unreasonable) or our impl of
>> GetSystemProperty() is wrong.
>>
>> It seems like in either case, we have a big problem still?
>
>
> Well, if there is no quick fix I would roll back the change to make CC
> happy.
>
> Thanks,
> Stepan.
>
> geir
>>
>> Stepan Mishura wrote:
>> > Gregory and Oliver,
>> >
>> > Could you have a look on your update to luniglob.c? It causes classlib
>> test
>> > failures on DRL VM. So if I rollback your update all classlib test pass
>> for
>> > me.
>> >
>> > Index: modules/luni/src/main/native/luni/shared/luniglob.c
>> > ===================================================================
>> > --- modules/luni/src/main/native/luni/shared/luniglob.c (revision
>> 486504)
>> > +++ modules/luni/src/main/native/luni/shared/luniglob.c (working copy)
>> > @@ -268,16 +268,8 @@
>> > unsigned i = 0;
>> > /* Make a string version of the CP separator */
>> > char cpSeparator[] = {(char)hysysinfo_get_classpathSeparator
>> (),
>> > '\0'};
>> > -
>> > - /* Read current value of bootclasspath property */
>> > - rcGetProperty = (*vmInterface)->GetSystemProperty
>> (vmInterface,
>> > - BOOTCLASSPATH_PROPERTY,
>> > - &bootstrapClassPath);
>> > + bootstrapClassPath = "";
>> >
>> > - /* Gregory - no property is found, VM bootclasspath is not
>> defined
>> > */
>> > - if (VMI_ERROR_NONE != rcGetProperty)
>> > - bootstrapClassPath = NULL;
>> > -
>> > qsort(props, number, sizeof(key_value_pair), props_compare);
>> >
>> > for (;i < number; i++)
>> >
>> > Thanks,
>> > Stepan.
>> >
>> > On 12/13/06, Stepan Mishura wrote:
>> >
>> >> On 12/13/06, Vladimir Ivanov wrote:
>> >> >
>> >> > CC is failed to run classlib tests over the DRLVM won windows and
>> linux
>> >> > with
>> >> > messages:
>> >> >
>> >> > Unit Test Error Details: (581) Test: testGetAccessibleAction
>> >> > Class:
>> >> > java.awt.AccessibleAWTCheckboxMenuItemTest
>> >> > java.lang.NoClassDefFoundError: javax/accessibility/Accessible
>> Test:
>> >> > testGetAccessibleRole Class:
>> >> java.awt.AccessibleAWTCheckboxMenuItemTest
>> >> > java.lang.NoClassDefFoundError : javax/accessibility/Accessible
>> >> > Could somebody reproduce it?
>> >>
>> >>
>> >> I can reproduce it. It seems that a cause is update for
>> >> bootstrapClassPath
>> >> in modules/luni/src/main/native/luni/shared/luniglob.c
>> (r486100-486378).
>> >>
>> >> I've rolled back them localy and this resolved classlib tests failures
>> on
>> >> DRL VM.
>> >>
>> >> Thanks,
>> >> Stepan
>> >>
>> >
>> >
>> >
>>
>
>
>
Re: [classlib][luni] update for bootstrapClassPath causes regression on DRL VM (was: Re: [drlvm][classlib] CC is failed to run classlib tests over the DRLVM)
Posted by Stepan Mishura <st...@gmail.com>.
On 12/13/06, Geir Magnusson Jr. wrote:
>
> Grrr. We had a thread last night "DRLVM broken on em64t" that you
> should read.
Sorry, I hadn't read the discussion when I wrote about regression.
In the end, what I was asking is if/how the behavior of
> GetSystemProperty() changed with our update to the property management
> inside of DRLVM, and the ramifications of that.
>
> Looking at Ollie's change in r486100, he seems to think that it's not an
> error to not have the property set, but our impl of GetSystemProperty it
> is.
>
> That's the issue I'm trying to get to - does the API of
> GetSystemProperty() specify that it returns an error code if the
> property isn't set?
>
> If so, then Ollie's code is wrong. If not, then it's either that the
> API is ambiguous (Ollie's assumption wasn't unreasonable) or our impl of
> GetSystemProperty() is wrong.
>
> It seems like in either case, we have a big problem still?
Well, if there is no quick fix I would roll back the change to make CC
happy.
Thanks,
Stepan.
geir
>
> Stepan Mishura wrote:
> > Gregory and Oliver,
> >
> > Could you have a look on your update to luniglob.c? It causes classlib
> test
> > failures on DRL VM. So if I rollback your update all classlib test pass
> for
> > me.
> >
> > Index: modules/luni/src/main/native/luni/shared/luniglob.c
> > ===================================================================
> > --- modules/luni/src/main/native/luni/shared/luniglob.c (revision
> 486504)
> > +++ modules/luni/src/main/native/luni/shared/luniglob.c (working copy)
> > @@ -268,16 +268,8 @@
> > unsigned i = 0;
> > /* Make a string version of the CP separator */
> > char cpSeparator[] = {(char)hysysinfo_get_classpathSeparator (),
> > '\0'};
> > -
> > - /* Read current value of bootclasspath property */
> > - rcGetProperty = (*vmInterface)->GetSystemProperty (vmInterface,
> > - BOOTCLASSPATH_PROPERTY,
> > - &bootstrapClassPath);
> > + bootstrapClassPath = "";
> >
> > - /* Gregory - no property is found, VM bootclasspath is not
> defined
> > */
> > - if (VMI_ERROR_NONE != rcGetProperty)
> > - bootstrapClassPath = NULL;
> > -
> > qsort(props, number, sizeof(key_value_pair), props_compare);
> >
> > for (;i < number; i++)
> >
> > Thanks,
> > Stepan.
> >
> > On 12/13/06, Stepan Mishura wrote:
> >
> >> On 12/13/06, Vladimir Ivanov wrote:
> >> >
> >> > CC is failed to run classlib tests over the DRLVM won windows and
> linux
> >> > with
> >> > messages:
> >> >
> >> > Unit Test Error Details: (581) Test: testGetAccessibleAction
> >> > Class:
> >> > java.awt.AccessibleAWTCheckboxMenuItemTest
> >> > java.lang.NoClassDefFoundError: javax/accessibility/Accessible
> Test:
> >> > testGetAccessibleRole Class:
> >> java.awt.AccessibleAWTCheckboxMenuItemTest
> >> > java.lang.NoClassDefFoundError : javax/accessibility/Accessible
> >> > Could somebody reproduce it?
> >>
> >>
> >> I can reproduce it. It seems that a cause is update for
> >> bootstrapClassPath
> >> in modules/luni/src/main/native/luni/shared/luniglob.c
> (r486100-486378).
> >>
> >> I've rolled back them localy and this resolved classlib tests failures
> on
> >> DRL VM.
> >>
> >> Thanks,
> >> Stepan
> >>
> >
> >
> >
>
--
Stepan Mishura
Intel Enterprise Solutions Software Division
Re: [classlib][luni] update for bootstrapClassPath causes regression on DRL VM (was: Re: [drlvm][classlib] CC is failed to run classlib tests over the DRLVM)
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 12/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> Grrr. We had a thread last night "DRLVM broken on em64t" that you
> should read.
>
> In the end, what I was asking is if/how the behavior of
> GetSystemProperty() changed with our update to the property management
> inside of DRLVM, and the ramifications of that.
>
> Looking at Ollie's change in r486100, he seems to think that it's not an
> error to not have the property set, but our impl of GetSystemProperty it
> is.
>
> That's the issue I'm trying to get to - does the API of
> GetSystemProperty() specify that it returns an error code if the
> property isn't set?
>
> If so, then Ollie's code is wrong. If not, then it's either that the
> API is ambiguous (Ollie's assumption wasn't unreasonable) or our impl of
> GetSystemProperty() is wrong.
>
> It seems like in either case, we have a big problem still?
Yes. In addition to ~600 failed classlib tests today the Eclipse failed to
start over the DRLVM (svn = r486494, (Dec 13 2006)).
Thanks, Vladimir
geir
>
> Stepan Mishura wrote:
> > Gregory and Oliver,
> >
> > Could you have a look on your update to luniglob.c? It causes classlib
> test
> > failures on DRL VM. So if I rollback your update all classlib test pass
> for
> > me.
> >
> > Index: modules/luni/src/main/native/luni/shared/luniglob.c
> > ===================================================================
> > --- modules/luni/src/main/native/luni/shared/luniglob.c (revision
> 486504)
> > +++ modules/luni/src/main/native/luni/shared/luniglob.c (working copy)
> > @@ -268,16 +268,8 @@
> > unsigned i = 0;
> > /* Make a string version of the CP separator */
> > char cpSeparator[] = {(char)hysysinfo_get_classpathSeparator (),
> > '\0'};
> > -
> > - /* Read current value of bootclasspath property */
> > - rcGetProperty = (*vmInterface)->GetSystemProperty (vmInterface,
> > - BOOTCLASSPATH_PROPERTY,
> > - &bootstrapClassPath);
> > + bootstrapClassPath = "";
> >
> > - /* Gregory - no property is found, VM bootclasspath is not
> defined
> > */
> > - if (VMI_ERROR_NONE != rcGetProperty)
> > - bootstrapClassPath = NULL;
> > -
> > qsort(props, number, sizeof(key_value_pair), props_compare);
> >
> > for (;i < number; i++)
> >
> > Thanks,
> > Stepan.
> >
> > On 12/13/06, Stepan Mishura wrote:
> >
> >> On 12/13/06, Vladimir Ivanov wrote:
> >> >
> >> > CC is failed to run classlib tests over the DRLVM won windows and
> linux
> >> > with
> >> > messages:
> >> >
> >> > Unit Test Error Details: (581) Test: testGetAccessibleAction
> >> > Class:
> >> > java.awt.AccessibleAWTCheckboxMenuItemTest
> >> > java.lang.NoClassDefFoundError: javax/accessibility/Accessible
> Test:
> >> > testGetAccessibleRole Class:
> >> java.awt.AccessibleAWTCheckboxMenuItemTest
> >> > java.lang.NoClassDefFoundError : javax/accessibility/Accessible
> >> > Could somebody reproduce it?
> >>
> >>
> >> I can reproduce it. It seems that a cause is update for
> >> bootstrapClassPath
> >> in modules/luni/src/main/native/luni/shared/luniglob.c
> (r486100-486378).
> >>
> >> I've rolled back them localy and this resolved classlib tests failures
> on
> >> DRL VM.
> >>
> >> Thanks,
> >> Stepan
> >>
> >
> >
> >
>
Re: [classlib][luni] update for bootstrapClassPath causes regression
on DRL VM (was: Re: [drlvm][classlib] CC is failed to run classlib tests
over the DRLVM)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Grrr. We had a thread last night "DRLVM broken on em64t" that you
should read.
In the end, what I was asking is if/how the behavior of
GetSystemProperty() changed with our update to the property management
inside of DRLVM, and the ramifications of that.
Looking at Ollie's change in r486100, he seems to think that it's not an
error to not have the property set, but our impl of GetSystemProperty it is.
That's the issue I'm trying to get to - does the API of
GetSystemProperty() specify that it returns an error code if the
property isn't set?
If so, then Ollie's code is wrong. If not, then it's either that the
API is ambiguous (Ollie's assumption wasn't unreasonable) or our impl of
GetSystemProperty() is wrong.
It seems like in either case, we have a big problem still?
geir
Stepan Mishura wrote:
> Gregory and Oliver,
>
> Could you have a look on your update to luniglob.c? It causes classlib test
> failures on DRL VM. So if I rollback your update all classlib test pass for
> me.
>
> Index: modules/luni/src/main/native/luni/shared/luniglob.c
> ===================================================================
> --- modules/luni/src/main/native/luni/shared/luniglob.c (revision 486504)
> +++ modules/luni/src/main/native/luni/shared/luniglob.c (working copy)
> @@ -268,16 +268,8 @@
> unsigned i = 0;
> /* Make a string version of the CP separator */
> char cpSeparator[] = {(char)hysysinfo_get_classpathSeparator (),
> '\0'};
> -
> - /* Read current value of bootclasspath property */
> - rcGetProperty = (*vmInterface)->GetSystemProperty (vmInterface,
> - BOOTCLASSPATH_PROPERTY,
> - &bootstrapClassPath);
> + bootstrapClassPath = "";
>
> - /* Gregory - no property is found, VM bootclasspath is not defined
> */
> - if (VMI_ERROR_NONE != rcGetProperty)
> - bootstrapClassPath = NULL;
> -
> qsort(props, number, sizeof(key_value_pair), props_compare);
>
> for (;i < number; i++)
>
> Thanks,
> Stepan.
>
> On 12/13/06, Stepan Mishura wrote:
>
>> On 12/13/06, Vladimir Ivanov wrote:
>> >
>> > CC is failed to run classlib tests over the DRLVM won windows and linux
>> > with
>> > messages:
>> >
>> > Unit Test Error Details: (581) Test: testGetAccessibleAction
>> > Class:
>> > java.awt.AccessibleAWTCheckboxMenuItemTest
>> > java.lang.NoClassDefFoundError: javax/accessibility/Accessible Test:
>> > testGetAccessibleRole Class:
>> java.awt.AccessibleAWTCheckboxMenuItemTest
>> > java.lang.NoClassDefFoundError : javax/accessibility/Accessible
>> > Could somebody reproduce it?
>>
>>
>> I can reproduce it. It seems that a cause is update for
>> bootstrapClassPath
>> in modules/luni/src/main/native/luni/shared/luniglob.c (r486100-486378).
>>
>> I've rolled back them localy and this resolved classlib tests failures on
>> DRL VM.
>>
>> Thanks,
>> Stepan
>>
>
>
>