|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
[jira] Created: (RVM-836) Static initialization loop in Generational collectorsStatic 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[ 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[ 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 |
| Free embeddable forum powered by Nabble | Forum Help |