On Mon, Jan 5, 2009 at 11:41 AM, Nathan Beyer <[email protected]> wrote: > On Sun, Jan 4, 2009 at 9:31 PM, Xiao-Feng Li <[email protected]> wrote: >> On Mon, Jan 5, 2009 at 1:20 AM, Nathan Beyer <[email protected]> wrote: >>> On Sun, Jan 4, 2009 at 5:26 AM, Xiao-Feng Li <[email protected]> wrote: >>>> Thanks. Then it is an issue blocking EUT3.5. >>>> >>>> Can we simply do not invoke any static method of a class under >>>> initialization? >>>> >>> >>> I don't think that's going to work, as that would result in the same >>> error in Eclipse we see today, which is a NPE exception because a >>> field isn't populated. If the static method isn't invoked, then the >>> field will still be null and we'd still have the same error. >> >> As Chunrong said, it is ok to return NULL (i.e., it passes the test) >> when the static method of an initializing class is invoked? Need >> confirmation from Chunrong. >> >> In my understanding, an object (a class object here) is created with >> all the fields (including static data) initialized with default >> values. So if we simply skip all the static method invocations, we >> will read all the default values. Well yes, this is still incorrect >> according to the spec. But the spec doesn't permit the static method >> of an initializing method being called. I don't know if the code >> itself is compliant with the spec. > > I couldn't find anything in the spec to say it was not compliant. It > just seems unexpected. I would say that it's undefined. It might be > worth while to post a bug/enhancement to Eclipse to eliminate the > circularity.
I found this in VM spec (2nd edition): Section 2.17.4 "(Class) Initialization": A class or interface type T will be initialized immediately before one of the following occurs: 1. T is a class and an instance of T is created. 2. T is a class and a static method of T is invoked. 3. A nonconstant static field of T is used or assigned. > However, even if it's not in the spec, all of the Eclipse standardized > platforms (JREs) seem to accept it, so it would certainly be tough to > not support it. Agreed. We need find a solution. > -Nathan > >> >> Thanks, >> xiaofeng >> >>>> This needs to add a check in the prolog of the static method on the >>>> initialization status of the owning class. It should not incur serious >>>> performance issue since it is a memory load plus a check. >>>> >>>> Is this VM SPEC expected behavior? >>> >>> Could any of the IBM folks on the list get some advice from some class >>> loader experts? >>> >>> -Nathan >>> >>>> >>>> Thanks, >>>> xiaofeng >>>> >>>> On Sun, Jan 4, 2009 at 6:29 PM, chunrong lai <[email protected]> wrote: >>>>> hi, xiaofeng: >>>>> Observing similar class initializing trace in the logfile of EUT35, I >>>>> see HARMONY can not pass EUT35 if we do not fix HARMONY-6020. >>>>> >>>>> I did a quick test to modify some usings of the return non-inited >>>>> value, >>>>> for example, processing of the bytecode of AALOAD. The test does make >>>>> Harmony pass some similar tests but still fail in other consuming cases. I >>>>> think that we just can not manually cover all of the consuming cases so we >>>>> need to fix the issue in the producing places. I am still trying this. >>>>> Lai, chunrong >>>>> Managed Runtime Technology Center, Intel >>>>> On Sun, Jan 4, 2009 at 2:59 PM, Xiao-Feng Li <[email protected]> >>>>> wrote: >>>>> >>>>>> See https://issues.apache.org/jira/browse/HARMONY-6020 >>>>>> >>>>>> A static method is invoked when its owning class is under >>>>>> initialization. Should we simply return without really executing any >>>>>> code of the method? >>>>>> >>>>>> In normal case, I think the calling thread will wait till the class >>>>>> initialization is done, then continue the invocation. In this case, >>>>>> the calling thread is the initializing thread, and this invocation >>>>>> actually is part of the initialization sequence. >>>>>> >>>>>> I personally would like to throw an exception since I regard the code >>>>>> as problematic. But if RI can pass the test case, and more importantly >>>>>> if EUT depends on it, we probably should find a solution. >>>>>> >>>>>> Chunrong, do you know if EUT can pass (or continue) when this issue is >>>>>> resolved? >>>>>> >>>>>> Thanks, >>>>>> xiaofeng >>>>>> >>>>>> On Sun, Jan 4, 2009 at 2:46 PM, Xiao-Feng Li (JIRA) <[email protected]> >>>>>> wrote: >>>>>> > >>>>>> > [ >>>>>> https://issues.apache.org/jira/browse/HARMONY-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660536#action_12660536] >>>>>> > >>>>>> > Xiao-Feng Li commented on HARMONY-6020: >>>>>> > --------------------------------------- >>>>>> > >>>>>> > When we look at this class definition: >>>>>> > >>>>>> > class Parent { >>>>>> > private static final Child[] childCache = new Child[5]; >>>>>> > >>>>>> > public static Child createChild(){ >>>>>> > return childCache[0]; >>>>>> > } >>>>>> > } >>>>>> > >>>>>> > It is clear that, the semantics expectation is, childCache should be >>>>>> assigned a value when class Parent is ready (i.e., initialized). And this >>>>>> value should be assigned to childCache before anybody can access any >>>>>> Parent's method, e.g., createChild(). This is the semantics expectation. >>>>>> I >>>>>> guess we need to ensure this semantics. >>>>>> > >>>>>> > Can we simply let this Child clinit() execute in this way: When it >>>>>> > tries >>>>>> to call Parent.createChild() and finds Parent is under initialization, it >>>>>> simply returns null to ROOT without really invoking createChild(). >>>>>> > >>>>>> > According to the JVM spec 2.17.4, it requires any static method >>>>>> invocation must happen after the class is "initialized." The problem is, >>>>>> how >>>>>> to deal with the situation when a static method is invoked when the >>>>>> owning >>>>>> class is under initialization. >>>>>> > >>>>>> > Thanks, >>>>>> > xiaofeng >>>>>> > >>>>>> > >>>>>> >> [DRLVM] Cyclical class dependency causes a failure not seen in RI >>>>>> >> ----------------------------------------------------------------- >>>>>> >> >>>>>> >> Key: HARMONY-6020 >>>>>> >> URL: >>>>>> >> https://issues.apache.org/jira/browse/HARMONY-6020 >>>>>> >> Project: Harmony >>>>>> >> Issue Type: Bug >>>>>> >> Components: DRLVM >>>>>> >> Affects Versions: 5.0M8 >>>>>> >> Environment: Win Vista 32-bit >>>>>> >> Reporter: Nathan Beyer >>>>>> >> Assignee: Chunrong Lai >>>>>> >> Attachments: cycle-project.zip >>>>>> >> >>>>>> >> >>>>>> >> If two classes have a cyclical dependency, some unexpected results may >>>>>> occur, which are not seen on RI (Sun 6u10). >>>>>> > >>>>>> > -- >>>>>> > This message is automatically generated by JIRA. >>>>>> > - >>>>>> > You can reply to this email to add a comment to the issue online. >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Xiao-Feng Li >>>>>> Managed Runtime Technology Center, Intel >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Managed Runtime Technology Center, Intel >>>> >>> >> >> >> >> -- >> Managed Runtime Technology Center, Intel >> > -- Managed Runtime Technology Center, Intel
