[jira] Created: (RVM-836) Static initialization loop in Generational collectors

View: New views
3 Messages — Rating Filter:   Alert me  

[jira] Created: (RVM-836) Static initialization loop in Generational collectors

by JIRA jira@codehaus.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Static initialization loop in Generational collectors
-----------------------------------------------------

                 Key: RVM-836
                 URL: http://jira.codehaus.org/browse/RVM-836
             Project: RVM
          Issue Type: Bug
          Components: MMTk
            Reporter: Robin Garner
            Assignee: Robin Garner


The GenConstraints class depends on several constants in the class Gen, eg
  public boolean needsStaticWriteBarrier() { return Gen.USE_STATIC_WRITE_BARRIER; }
  public boolean needsLogBitInHeader() { return Gen.USE_OBJECT_BARRIER; }
  public int maxNonLOSDefaultAllocBytes() { return Gen.MAX_NURSERY_ALLOC_BYTES; }

The first two are resolved at compile-time by javac, the last compiles to
public int maxNonLOSDefaultAllocBytes();
  Code:
   0: getstatic #3; //Field org/mmtk/plan/generational/Gen.MAX_NURSERY_ALLOC_BYTES:I
   3: ireturn

which causes the Plan class hierarchy to be statically initialized.  Since Plan says

  public static final int MAX_NON_LOS_DEFAULT_ALLOC_BYTES = VM.activePlan.constraints().maxNonLOSDefaultAllocBytes();

there is a loop.  The JikesRVM bootstrap process somehow resolves this correctly, but in the MMTk harness this constant ends up as zero.

The obvious solution is to lift this calculation into the GenConstraints class, since it's only ever used there.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues

[jira] Work started: (RVM-836) Static initialization loop in Generational collectors

by JIRA jira@codehaus.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


     [ http://jira.codehaus.org/browse/RVM-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on RVM-836 started by Robin Garner.

> Static initialization loop in Generational collectors
> -----------------------------------------------------
>
>                 Key: RVM-836
>                 URL: http://jira.codehaus.org/browse/RVM-836
>             Project: RVM
>          Issue Type: Bug
>          Components: MMTk
>            Reporter: Robin Garner
>            Assignee: Robin Garner
>
> The GenConstraints class depends on several constants in the class Gen, eg
>   public boolean needsStaticWriteBarrier() { return Gen.USE_STATIC_WRITE_BARRIER; }
>   public boolean needsLogBitInHeader() { return Gen.USE_OBJECT_BARRIER; }
>   public int maxNonLOSDefaultAllocBytes() { return Gen.MAX_NURSERY_ALLOC_BYTES; }
> The first two are resolved at compile-time by javac, the last compiles to
> public int maxNonLOSDefaultAllocBytes();
>   Code:
>    0: getstatic #3; //Field org/mmtk/plan/generational/Gen.MAX_NURSERY_ALLOC_BYTES:I
>    3: ireturn
> which causes the Plan class hierarchy to be statically initialized.  Since Plan says
>   public static final int MAX_NON_LOS_DEFAULT_ALLOC_BYTES = VM.activePlan.constraints().maxNonLOSDefaultAllocBytes();
> there is a loop.  The JikesRVM bootstrap process somehow resolves this correctly, but in the MMTk harness this constant ends up as zero.
> The obvious solution is to lift this calculation into the GenConstraints class, since it's only ever used there.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues

[jira] Closed: (RVM-836) Static initialization loop in Generational collectors

by JIRA jira@codehaus.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


     [ http://jira.codehaus.org/browse/RVM-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robin Garner closed RVM-836.
----------------------------

       Resolution: Fixed
    Fix Version/s: 3.1.1

Fixed in r15717

> Static initialization loop in Generational collectors
> -----------------------------------------------------
>
>                 Key: RVM-836
>                 URL: http://jira.codehaus.org/browse/RVM-836
>             Project: RVM
>          Issue Type: Bug
>          Components: MMTk
>            Reporter: Robin Garner
>            Assignee: Robin Garner
>             Fix For: 3.1.1
>
>
> The GenConstraints class depends on several constants in the class Gen, eg
>   public boolean needsStaticWriteBarrier() { return Gen.USE_STATIC_WRITE_BARRIER; }
>   public boolean needsLogBitInHeader() { return Gen.USE_OBJECT_BARRIER; }
>   public int maxNonLOSDefaultAllocBytes() { return Gen.MAX_NURSERY_ALLOC_BYTES; }
> The first two are resolved at compile-time by javac, the last compiles to
> public int maxNonLOSDefaultAllocBytes();
>   Code:
>    0: getstatic #3; //Field org/mmtk/plan/generational/Gen.MAX_NURSERY_ALLOC_BYTES:I
>    3: ireturn
> which causes the Plan class hierarchy to be statically initialized.  Since Plan says
>   public static final int MAX_NON_LOS_DEFAULT_ALLOC_BYTES = VM.activePlan.constraints().maxNonLOSDefaultAllocBytes();
> there is a loop.  The JikesRVM bootstrap process somehow resolves this correctly, but in the MMTk harness this constant ends up as zero.
> The obvious solution is to lift this calculation into the GenConstraints class, since it's only ever used there.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues