Daniel A. Ehrenberg wrote:
> Running it on one processor produced the same results, it looks like. I looked in RVM.map and in both versions the TIB for SSTraceLocal was very near the beginning of a page. I'm not sure what other classes might affect this locality. Anyway, the 5% difference I'm reporting should probably be a result of the layout in the data heap, as I'm not looking at locality during garbage collection. But I guess it could also be a much broader and more complicated artifact of heap layout than the classes involved in garbage collection.
>
> Incidentally, do you happen to have a version of your RVM-515 patch that works with the current development version of Jikes? (I've gotten it working with the version it was written for, but this isn't optimal.)
>
> Dan
>
Hi Dan,
sorry I've not got an updated version of RVM-515, I'll try to do it
after 3.0 is released. My plan is to parallelize the object graph
traversal to hopefully negate the stack overhead. Once the speed is on a
par with current boot image writing I'll try to get it into a release,
hopefully 3.0.1. Feel free to help me out though, or vote for this issue
in JIRA :-)
Regards,
Ian
> ----- Original Message -----
> From: "Ian Rogers" <rogers.email@...>
> To: "General discussion of Jikes RVM design, implementation, issues, and plans" <jikesrvm-researchers@...>
> Sent: Tuesday, July 29, 2008 6:14:23 PM GMT -08:00 US/Canada Pacific
> Subject: Re: [rvm-research] Mutator locality of different GC algorithms
>
> Hi Dan,
>
> I'm certainly puzzled by the ~5% difference in DTLB misses you are
> seeing. First of all, are you running the tests on >1 processor
> (-X:processors=all, etc.) ? I'm not sure on the sanity of running
> perfctr on >1 processor and maybe you need something like oprofile. The
> method dispatch code for completeTrace being in TraceLocal and
> SSTraceLocal is the same for BaseBase configurations. You may be seeing
> a boot image layout issue, especially if you do a parallel boot image
> build. If you look in the RVM.map generated in the target/BaseBase.../
> directory you can see the location of TIBs as they always have a JTOC
> location. If you see that the TIB is close to a page boundary then maybe
> this has affected your first run. RVM-515 [1] has a patch that allows
> tweaking of the boot image layout.
>
> Regards,
> Ian Rogers
> [1] http://jira.codehaus.org/browse/RVM-515
> --
> http://www.ifmt.org/
> First International Forum on Next-Generation Multicore/Manycore
> Technologies IFMT’08
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>

Running it on one processor produced the same results, it looks like. I looked in RVM.map and in both versions the TIB for SSTraceLocal was very near the beginning of a page. I'm not sure what other classes might affect this locality. Anyway, the 5% difference I'm reporting should probably be a result of the layout in the data heap, as I'm not looking at locality during garbage collection. But I guess it could also be a much broader and more complicated artifact of heap layout than the classes involved in garbage collection.
Incidentally, do you happen to have a version of your RVM-515 patch that works with the current development version of Jikes? (I've gotten it working with the version it was written for, but this isn't optimal.)
Dan
----- Original Message -----
From: "Ian Rogers" <rogers.email@...>
To: "General discussion of Jikes RVM design, implementation, issues, and plans" <jikesrvm-researchers@...>
Sent: Tuesday, July 29, 2008 6:14:23 PM GMT -08:00 US/Canada Pacific
Subject: Re: [rvm-research] Mutator locality of different GC algorithms
Hi Dan,
I'm certainly puzzled by the ~5% difference in DTLB misses you are
seeing. First of all, are you running the tests on >1 processor
(-X:processors=all, etc.) ? I'm not sure on the sanity of running
perfctr on >1 processor and maybe you need something like oprofile. The
method dispatch code for completeTrace being in TraceLocal and
SSTraceLocal is the same for BaseBase configurations. You may be seeing
a boot image layout issue, especially if you do a parallel boot image
build. If you look in the RVM.map generated in the target/BaseBase.../
directory you can see the location of TIBs as they always have a JTOC
location. If you see that the TIB is close to a page boundary then maybe
this has affected your first run. RVM-515 [1] has a patch that allows
tweaking of the boot image layout.
Regards,
Ian Rogers
[1] http://jira.codehaus.org/browse/RVM-515
--
http://www.ifmt.org/
First International Forum on Next-Generation Multicore/Manycore
Technologies IFMT’08

Second international workshop on Virtual Machines and Intermediate
Languages for emerging modularization mechanisms (VMIL 2008) - a
one-day workshop affiliated with OOPSLA 2008.
http://www.cs.iastate.edu/~design/vmil/
Submission URL: http://www.easychair.org/conferences/?conf=VMIL-08
Important Dates
Submission Deadline: Aug 15, 2008, 23:59 Samoan
Notification of Acceptance: Sept 4, 2008
Camera ready copy due: Oct 1, 2008
Workshop: Oct 19, 2008
Program Committee
* Eric Bodden (McGill University, Canada)
* Juan Chen (Microsoft Research, USA)
* Shigeru Chiba (Tokyo Institute of Technology, Japan)
* Sophia Drossopoulou (Imperial College, UK)
* Eric Eide (University of Utah, USA)
* Matthew Flatt (University of Utah, USA)
* Gregor Kiczales (University of British Columbia, Canada)
* Hidehiko Masuhara (University of Tokyo, Japan)
* Greg Morrisett (Harvard University, USA)
* Angela Nicoara (ETH Zurich, Switzerland)
* Harold Ossher (IBM Research, USA)
* and the organizers
Organizers
* Hridesh Rajan, (Iowa State University, USA)
* Christoph Bockisch, (Darmstadt University of Technology)
* Michael Haupt (Hasso Plattner Institute, University of Potsdam, Germany)
* Robert Dyer (Iowa State University, USA)
Motivation and Objectives
Modern programming languages are compiled to intermediate code
preserving the intention of high-level language constructs. Emerging
modularization mechanisms, however, lack such handling. Recent
research results have shown that deeper support for these
modularization mechanisms, e.g., in virtual machines and intermediate
languages, is feasible; it allows applying tailored optimizations and
radically improves development processes such as incremental
compilation, debugging, etc.
The VMIL workshop, second in the series, is a forum for research in
virtual machines and intermediate languages with support for emerging
modularization mechanisms such as mix-ins, units, open classes,
hyper-slices, adaptive methods, roles, composition filters, layers,
pointcuts-and-advice, and inter-type declarations. Topics of interest
include, but are not limited to: compilation-based and
interpreter-based virtual machines as well as intermediate language
designs with dedicated support for emerging modularization mechanisms,
compilation techniques, optimization strategies, improved techniques
for fast predicate evaluation (e.g., of pointcuts) inside virtual
machines, and advanced caching and memory management schemes.
The areas of interest include, but are not limited to:
compilation-based and interpreter-based virtual machine as well as
intermediate language designs that better support these emerging
modularization mechanisms, intermediate language constructs that
better support these modularization mechanisms, compilation techniques
from high-level languages to enhanced intermediate languages,
optimization strategies for reduction of runtime overhead due to
either compilation or interpretation, improved techniques for fast
evaluation of pointcuts and other predicates inside virtual machines,
use cases for deeper support in the virtual machines and intermediate
languages, advanced caching and memory management schemes in support
of the mechanisms.
Paper Categories
In these key areas, we invite high-quality papers in the following two
categories.
* Research and experience papers: These submissions should describe
work that advances the current state of the art in support of advanced
separation of concerns techniques in virtual machines and intermediate
languages. Experience papers that are of broader interest and describe
insights gained from practical applications. The page limit for these
submissions is 10 pages.
* Position papers: These submissions present and defend the author/s
position on a topic related to the broader area of the workshop. The
page limit for these submissions is 6 pages.
Review Process
The program committee will evaluate each paper based on its relevance,
significance, clarity and originality. Each submission will be
reviewed by at least three PC members.
Paper Submission
Papers should be submitted in PDF format at the submission URL
http://www.easychair.org/conferences/?conf=VMIL-08. The results
described must be unpublished and must not be under review for another
workshop, conference or journal. Submissions must conform to ACM
SIGPLAN format and must not exceed the page limit of the category in
which it is classified by authors (including all text, figures,
references and appendices). Submissions which do not conform to this
will be desk rejected without reviews.

Daniel A. Ehrenberg wrote:
> Hi,
>
> I'm trying to do some performance analysis on garbage collectors in the Jikes RVM. Benchmarking mutator DTLB misses using perfctr, I'm getting some unexpected results. It seems like if I copy the definition of completeTrace() from TraceLocal.java into SSTraceLocal.java, the number of DTLB misses as the *mutator* runs is affected. This, to me, makes no sense at all, and the variation caused by this seems to be almost as great as the difference between breadth-first and depth-first search in informal tests of mine.
>
> Here's a test case: With svn checked out last night, running BaseBaseSemiSpace on an Intel Core 2 computer, I get a median of 16582396 mutator DTLB misses running the DaCapo HSQLDB benchmark on the default data set, but if I copy the completeTrace() method from TraceLocal to SSTraceLocal, I get a median of 15689842 mutator DTLB misses. Over a few trials, the ranges of this are non-overlapping. This is a significant proportion, and it's interfering with my other benchmarks since certain new garbage collectors I'm testing need to override completeTrace().
>
> Between svn checkouts of Jikes, these numbers also vary (and sometimes the difference goes in the opposite direction, though it's consistent within a checkout), but I can accept that. Obviously I'm doing something wrong here, and I was wondering if anyone here had an idea of what might be going wrong or how to go about figuring this out. Maybe this has to do with the code layout in the image, but the effect seems too large to attribute to that.
>
> Thanks,
>
> Dan Ehrenberg
>
Hi Dan,
I'm certainly puzzled by the ~5% difference in DTLB misses you are
seeing. First of all, are you running the tests on >1 processor
(-X:processors=all, etc.) ? I'm not sure on the sanity of running
perfctr on >1 processor and maybe you need something like oprofile. The
method dispatch code for completeTrace being in TraceLocal and
SSTraceLocal is the same for BaseBase configurations. You may be seeing
a boot image layout issue, especially if you do a parallel boot image
build. If you look in the RVM.map generated in the target/BaseBase.../
directory you can see the location of TIBs as they always have a JTOC
location. If you see that the TIB is close to a page boundary then maybe
this has affected your first run. RVM-515 [1] has a patch that allows
tweaking of the boot image layout.
Regards,
Ian Rogers
[1] http://jira.codehaus.org/browse/RVM-515
--
http://www.ifmt.org/
First International Forum on Next-Generation Multicore/Manycore
Technologies IFMT’08

Hi,
I'm trying to do some performance analysis on garbage collectors in the Jikes RVM. Benchmarking mutator DTLB misses using perfctr, I'm getting some unexpected results. It seems like if I copy the definition of completeTrace() from TraceLocal.java into SSTraceLocal.java, the number of DTLB misses as the *mutator* runs is affected. This, to me, makes no sense at all, and the variation caused by this seems to be almost as great as the difference between breadth-first and depth-first search in informal tests of mine.
Here's a test case: With svn checked out last night, running BaseBaseSemiSpace on an Intel Core 2 computer, I get a median of 16582396 mutator DTLB misses running the DaCapo HSQLDB benchmark on the default data set, but if I copy the completeTrace() method from TraceLocal to SSTraceLocal, I get a median of 15689842 mutator DTLB misses. Over a few trials, the ranges of this are non-overlapping. This is a significant proportion, and it's interfering with my other benchmarks since certain new garbage collectors I'm testing need to override completeTrace().
Between svn checkouts of Jikes, these numbers also vary (and sometimes the difference goes in the opposite direction, though it's consistent within a checkout), but I can accept that. Obviously I'm doing something wrong here, and I was wondering if anyone here had an idea of what might be going wrong or how to go about figuring this out. Maybe this has to do with the code layout in the image, but the effect seems too large to attribute to that.
Thanks,
Dan Ehrenberg

Research Archive item #2030876, was opened at 2008-07-28 20:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=723235&aid=2030876&group_id=128805
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: xlhuang (xlhuang)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implementation of online object reordering (oopsla 2004)
Initial Comment:
STATEMENT OF ORIGIN FOR A SINGLE CONTRIBUTOR
I, Xianglong Huang:
(a) represent that either:
(i) I am the only author and owner of the contributed software
(described as/entitled Online Object Reordering implementation),
which was neither derived nor copied from any other software,
or
(ii) that any exception to (i) is software which was obtained under the
CPL (Common Public License),
and
(b) hereby agree to license this contributed software under the CPL.
Description:
This patch is the implementation of Online Object Reordering
(OOR) algorithm from the OOPSLA 2004. This patch works
with JikesRVM version 2.9.3. This algorithm only works with GenCopy garbage collector. The commandline options this patch added are:
-X:aos:oor=true // running oor optimization during the adaptive optimizing compilation. Default is "false"
-X:gc:copyOrder // when given value "oor", it uses runtime information collected by adaptive compilation to direct copying objects into the older generation. the value of this option can also be "breadthfirst" or "depthfirst". Default is "depthfirst".
--X:aos:bb_threshold //This is a "hotness" threshold used by adaptive compilation. Only basic block with higher than this threshold "hotness" will be considered in the oor analysis. Default value is 0.5
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=723235&aid=2030876&group_id=128805

Hi Zvi,
I believe ObjectReferences are traced during GC but Addresses are not.
So if you don't want your object to be traced, store the reference in an
Address instead.
-Eddie
Zvi Effron wrote:
> I have an interesting bug in my code where if I don't null out a global
> ObjectReference that I use during collection to refer to dead objects, the
> last object I work with is found during the tracing phase of the next
> garbage collection. This leads me to wonder if occurrences of
> ObjectReference that are live are traced during Garbage Collection, as I was
> under the assumption that they weren't since they were an Unboxed type.
>
> Zvi Effron
> Harvey Mudd College

I have an interesting bug in my code where if I don't null out a global
ObjectReference that I use during collection to refer to dead objects, the
last object I work with is found during the tracing phase of the next
garbage collection. This leads me to wonder if occurrences of
ObjectReference that are live are traced during Garbage Collection, as I was
under the assumption that they weren't since they were an Unboxed type.
Zvi Effron
Harvey Mudd College
--
View this message in context: http://www.nabble.com/Are-ObjectReferences-traced-during-garbage-collection--tp18595679p18595679.html
Sent from the jikesrvm-researchers mailing list archive at Nabble.com.

Ken Lee wrote:
> Hi Ian,
>
> Do you mean that I should use object literals for all VM_Field objects
> in the bootimage instead of int literals, i.e. rewriting the bootimage
> writer?
>
So the simplest thing to do is use object literals, if at runtime you
know an object won't move then you can use the instructions with an
immediate operand. ie:
protected final void emit_resolved_getstatic(VM_FieldReference fieldRef) {
if (fieldRef.getSize() <= BYTES_IN_INT) {
VM_Field field = fieldRef.peekResolvedField();
if (MM_Interface.willNeverMove(field) && VM.runningVM) {
int address = VM_Magic.objectAsAddress(field).toInt();
asm.emitMOV_Reg_Imm(T0, address);
} else {
Offset offset = VM_Statics.findOrCreateObjectLiteral(field);
asm.emitMOV_Reg_Abs(T0, Magic.getTocPointer().plus(offset));
}
asm.emitMOV_Reg_RegDisp(T1, T0, STATUS_HEADER_OFFSET);
asm.emitTEST_Reg_Imm_Word(T1, MARK_BIT);
VM_ForwardReference fr1 = asm.forwardJcc(VM_Assembler.EQ);
asm.emitPUSH_Reg(T0);
genParameterRegisterLoad(1);
asm.emitCALL_RegDisp(JTOC, VM_Entrypoints.foo.getOffset());
fr1.resolved(asm);
asm.emitPUSH_RegDisp(JTOC, fieldOffset);
} else {
...
}
> Another idea could be to add a boolean field in the VM_Field class. When
> a VM_Field object is "marked" during runtime, this flag is set to true.
> In the emit_getstatic method of the compiler, shouldn't I be able to
> test for this flag and then execute my code if it is set?
>
This sounds like new code and should be do-able, it all depends on what
end result you want.
Regards,
Ian
> Cheers,
>
> Ken
>
> Ian Rogers wrote:
>
>> Hi Ken,
>>
>> for what you are trying to do I'd suggest using an object literal in the
>> JTOC. You will need to load it from a fixed address, but this way the
>> boot image writer will fix up the address. To create the literal use
>> Statics.findOrCreate, you may need to increase your JTOC size.
>>
>> Regards,
>> Ian
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> Jikesrvm-researchers@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>

Hi Ian,
Do you mean that I should use object literals for all VM_Field objects
in the bootimage instead of int literals, i.e. rewriting the bootimage
writer?
Another idea could be to add a boolean field in the VM_Field class. When
a VM_Field object is "marked" during runtime, this flag is set to true.
In the emit_getstatic method of the compiler, shouldn't I be able to
test for this flag and then execute my code if it is set?
Cheers,
Ken
Ian Rogers wrote:
> Hi Ken,
>
> for what you are trying to do I'd suggest using an object literal in the
> JTOC. You will need to load it from a fixed address, but this way the
> boot image writer will fix up the address. To create the literal use
> Statics.findOrCreate, you may need to increase your JTOC size.
>
> Regards,
> Ian
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>

Ken Lee wrote:
> During runtime I would like to mark some VM_Field objects, particular
> those which represent static fields of classes by using a bit in the
> objects' status header.
> In the Baseline compiler for IA32 I extended the GET_STATIC_FIELD (and
> PUT_STATIC_FIELD) method to first check if the corresponding VM_Field
> object of the static field accessed is marked with the bit in its status
> header and then execute a method bar() by passing the VM_Field object.
>
> The modification looks something like this:
>
> protected final void emit_resolved_getstatic(VM_FieldReference fieldRef) {
> VM_Field field = fieldRef.peekResolvedField();
> Offset fieldOffset = field.getOffset();
> int address = VM_Magic.objectAsAddress(field).toInt();
>
> if (fieldRef.getSize() <= BYTES_IN_INT) {
> asm.emitMOV_Reg_Imm(T0, address);
> asm.emitMOV_Reg_RegDisp(T1, T0, STATUS_HEADER_OFFSET);
> asm.emitTEST_Reg_Imm_Word(T1, MARK_BIT);
> VM_ForwardReference fr1 = asm.forwardJcc(VM_Assembler.EQ);
> asm.emitPUSH_Reg(T0);
> genParameterRegisterLoad(1);
> asm.emitCALL_RegDisp(JTOC, VM_Entrypoints.foo.getOffset());
> fr1.resolved(asm);
> asm.emitPUSH_RegDisp(JTOC, fieldOffset);
> } else {
> ...
> }
> }
>
> When compiling an image, I was not able to start the RVM due to a "sp
> (0x57a6e340) too far below stackLimit (0x00000000) to recover" error
> message. With the help of some debugging outputs I found out that the
> VM_Field objects in the BootImage have a "strange" address like 0x2157
> which was the reason why the loading of the status header into a
> register failed.
> After discussing with Ian Rogers (thanks for the support btw!) we found
> out that "the address in the boot image writer is an int literal place
> holder for the real object". Ian suggested to wrap my code around a
> conditional if(VM.runningVM).
> Correct me if I'm wrong but when the bootimage writer compiles classes,
> the VM.runningVM variable is false at that time and when accessing a
> static field belonging to a bootimage class during runtime, my code will
> never be executed.
>
> A tested this shortly by instantiating an object of a class
>
> Foo {
> static int i;
> stati String s;
> }
>
> containing some static fields, marking their VM_Field objects with the
> corresponding bit and accessing those fields in the VM. The result
> although was that my code wasn't executed because of the above
> assumption, I think.
>
> Or does the BootImage only consists of bytecode which are compiled by
> the baseline (or optimising) compiler during runtime to machine code?
>
> Am I misunderstanding something?
>
> Cheers,
>
> Ken
Hi Ken,
for what you are trying to do I'd suggest using an object literal in the
JTOC. You will need to load it from a fixed address, but this way the
boot image writer will fix up the address. To create the literal use
Statics.findOrCreate, you may need to increase your JTOC size.
Regards,
Ian

On Thu, 17 Jul 2008, Leguia, Tony wrote:
> I've run into several odd and seemingly inconsistent problems while
> writing a GC for the JRVM. Is there any reason why arrays I create
> statically would be nulled out at runtime? Could it be that the spaces I
> create are being created over the same region of memory the array lies
> in (I am using discontiguous memory for my spaces )? I assumed objects
> such as arrays of this type would be allocated into the boot space but I
> seem to be mistaken. I tried determining if the address of my arrays
> coincide with the space regions taken up by my spaces, but unfortunately
> get a null pointer exception. What makes this problem truly confusing to
> me is that if I create an array and then initialize parts of it nothing
> bad occurs, but if I try to determine the address of the array, or
> access its contents I get the exception.
Hi Tony,
Arrays of class types in the boot image need to be declared explicitly in
the following file:
jikesrvm/build/primordials/RVM.txt
> Additionally, I seem unable to create an array that holds instant of a
> space class. Is this normal or a product of whatever is causing my
> arrays to be nulled? I have troubleshooted this issues for many hours
> and can't seem to find their cause. Any help would be greatly
> appreciated, this problem has me truly baffled.
I think this may be a related issue. What type is your array? Looking at
primordials/RVM.txt, Space[] is already included, i.e.,
[Lorg/mmtk/policy/Space;
but if the array has some other type (e.g., Object[] or
SomeCustomSpace[]), then you'll need to add that array type to
primordials/RVM.txt.
hope that helps,
Mike

Hello All,
I've run into several odd and seemingly inconsistent problems while writing a GC for the JRVM.
Is there any reason why arrays I create statically would be nulled out at runtime? Could it be that the spaces I create are being created over the same region of memory the array lies in (I am using discontiguous memory for my spaces )? I assumed objects such as arrays of this type would be allocated into the boot space but I seem to be mistaken. I tried determining if the address of my arrays coincide with the space regions taken up by my spaces, but unfortunately get a null pointer exception. What makes this problem truly confusing to me is that if I create an array and then initialize parts of it nothing bad occurs, but if I try to determine the address of the array, or access its contents I get the exception.
Additionally, I seem unable to create an array that holds instant of a space class. Is this normal or a product of whatever is causing my arrays to be nulled? I have troubleshooted this issues for many hours and can't seem to find their cause. Any help would be greatly appreciated, this problem has me truly baffled.
Sincerely,
Tony Leguia

During runtime I would like to mark some VM_Field objects, particular
those which represent static fields of classes by using a bit in the
objects' status header.
In the Baseline compiler for IA32 I extended the GET_STATIC_FIELD (and
PUT_STATIC_FIELD) method to first check if the corresponding VM_Field
object of the static field accessed is marked with the bit in its status
header and then execute a method bar() by passing the VM_Field object.
The modification looks something like this:
protected final void emit_resolved_getstatic(VM_FieldReference fieldRef) {
VM_Field field = fieldRef.peekResolvedField();
Offset fieldOffset = field.getOffset();
int address = VM_Magic.objectAsAddress(field).toInt();
if (fieldRef.getSize() <= BYTES_IN_INT) {
asm.emitMOV_Reg_Imm(T0, address);
asm.emitMOV_Reg_RegDisp(T1, T0, STATUS_HEADER_OFFSET);
asm.emitTEST_Reg_Imm_Word(T1, MARK_BIT);
VM_ForwardReference fr1 = asm.forwardJcc(VM_Assembler.EQ);
asm.emitPUSH_Reg(T0);
genParameterRegisterLoad(1);
asm.emitCALL_RegDisp(JTOC, VM_Entrypoints.foo.getOffset());
fr1.resolved(asm);
asm.emitPUSH_RegDisp(JTOC, fieldOffset);
} else {
...
}
}
When compiling an image, I was not able to start the RVM due to a "sp
(0x57a6e340) too far below stackLimit (0x00000000) to recover" error
message. With the help of some debugging outputs I found out that the
VM_Field objects in the BootImage have a "strange" address like 0x2157
which was the reason why the loading of the status header into a
register failed.
After discussing with Ian Rogers (thanks for the support btw!) we found
out that "the address in the boot image writer is an int literal place
holder for the real object". Ian suggested to wrap my code around a
conditional if(VM.runningVM).
Correct me if I'm wrong but when the bootimage writer compiles classes,
the VM.runningVM variable is false at that time and when accessing a
static field belonging to a bootimage class during runtime, my code will
never be executed.
A tested this shortly by instantiating an object of a class
Foo {
static int i;
stati String s;
}
containing some static fields, marking their VM_Field objects with the
corresponding bit and accessing those fields in the VM. The result
although was that my code wasn't executed because of the above
assumption, I think.
Or does the BootImage only consists of bytecode which are compiled by
the baseline (or optimising) compiler during runtime to machine code?
Am I misunderstanding something?
Cheers,
Ken

>史成荣 wrote:
>> hi, I want to do some work on Jikes RVM, and found there is a research archive page in JikesRVM's web site. But the research archive page(http://sourceforge.net/tracker/?atid=723235&group_id=128805&func=browse) can not open. Is the address of research archive page changed? How can I browse the research archives?
>>
>> Thanks,
>> Chengrong
>>
>Hi Chengrong,
>
>the research archive link you gave works for me in the UK. I've heard
>that China may be blocking parts of the source forge web site:
>
>http://developers.slashdot.org/article.pl?sid=08/06/26/2047220
>
>Perhaps we can migrate research archive items over to Codehaus and JIRA,
>is there something in particular you want access to?
>
>Regards,
>Ian Rogers
I am interested in program analysis technologys in multithread envirenment and want to access some related work. Can I get these research archive items elsewhere?

史成荣 wrote:
> hi, I want to do some work on Jikes RVM, and found there is a research archive page in JikesRVM's web site. But the research archive page(http://sourceforge.net/tracker/?atid=723235&group_id=128805&func=browse) can not open. Is the address of research archive page changed? How can I browse the research archives?
>
> Thanks,
> Chengrong
>
Hi Chengrong,
the research archive link you gave works for me in the UK. I've heard
that China may be blocking parts of the source forge web site:
http://developers.slashdot.org/article.pl?sid=08/06/26/2047220
Perhaps we can migrate research archive items over to Codehaus and JIRA,
is there something in particular you want access to?
Regards,
Ian Rogers
--
International Forum on Muticore/Manycore Technologies
Paper deadline July 31st
http://www.ifmt.org/

Eliot Moss wrote:
>
>> Eliot Moss wrote:
>>> And why do want the something different in the first place? (You may
>>> have
>>> very
>>> good reasons, but it tends ot be helpful to know them :-) ...)
>>>
>> As I think about it today, I can't recall all of my reasons for thinking
>> it
>> might be useful to put different techniques in different classes. What I
>> can recall is thinking that if every technique gets put into the same
>> file,
>> as more techniques are developed and implemented, the file will grow and
>> become more and more complex, which will make it much harder to work with
>> in
>> the future. Also, switching between techniques will require modifying
>> the
>> TraceGenerator class (since the boolean for MERLIN_ANALYSIS is there),
>> whereas splitting different techniques into different classes could allow
>> the switching to be done in the plan by simply switching which class is
>> used. I'm not sure how good those reasons are for warranting putting
>> different techniques in different classes, though.
>
> Sure -- perhaps there should be an abstract class or an interface
> describing
> the API to trace generation, and then a concrete class that one uses. This
> is
> not unlike the setup for choosing which GC to use, so I suggest you get a
> handle on how that is done at build time, etc. I strongly agree withb the
> principles involved in making different techniques separate, yet putting
> their
> commonality into a superclass or other shared program structure.
>
> Best wishes -- Eliot
>
I've been working on a simple refactoring of the trace generation code
(which I think will prove to be temporary, since I'm not sure there isn't a
better way to accomplish it. I'm currently working on reimplementing the
Merlin algorithm using that framework (since it needed to be fixed anyway,
as it is broken in 2.9.3). I have the base alforithm working correctly, but
I noticed that org.mmtk.utility.TraceGenerator.java had a function
boot(Address bootStart) that seemed to add objects in the bootimage to the
trace, if I'm not mistaken. In version 2.9.3, this code does not seem to be
called, so I was wondering if it was ever called, or if it was a leftover,
and if it used to be called when the trace generation worked, what was the
mechanism for calling it?
Zvi Effron
Harvey Mudd College
--
View this message in context: http://www.nabble.com/Is-it-possible-to-create-a-new-TraceGenerator-in-a-different-file-tp17993932p18450297.html
Sent from the jikesrvm-researchers mailing list archive at Nabble.com.

Hi Tony,
It's hard to say, but one possibility is that you're creating the
immortal space twice over. You may get more information by greatly
increasing the verbosity: "-X:gc:verbose=1000"
BTW, I see that you've created your GC as a contiguous space (ie
pinning down virtual memory for exclusive use by your space), whereas
we've mostly moved away from contiguous spaces. One of the advantages
of discontinuous spaces is that virtual memory is not pinned down.
--Steve
On 12/07/2008, at 4:36 AM, Leguia, Tony wrote:
> Hello all,
>
> I'm having a bit of a problem with a GC I wrote. When I attempt to
> run the rvm with my GC I get a conflicting virtual space request
> error.
> It is the following:
>
> Conflicting virtual address request for space "immortal" at 0x70000000
> Key: (I)mmortal (N)onmoving (D)iscontiguous (E)xtent (F)raction
> HEAP_START 0x60000000
> AVAILABLE_START 0x65800000
> boot IN 0x60000000->0x6fffffff E 0x10000000
> immortal IND []
> meta ND []
> los ND []
> plos N 0xaac00000->0xafffffff F 0.07
> sanity ND []
> non-moving ND []
> sm-code ND []
> lg-code ND []
> myGC-space 0x70000000->0x9cbfffff F 0.60
> AVAILABLE_END 0xb0000000
> HEAP_END 0xb0000000
> exiting
>
> It seems the immortal space is being set to the same region as myGC-
> space. But, I am unsure why this would occur. Is it because I am
> requesting too big a region for myGC-space? I was thinking of
> explicitly declaring what part of virtual memory I would like for my
> space so that perhaps immortal space and myGC-space would not
> coincide, but I feel like this would be a hack and not an actual
> solution to my problem.
> I will continue to fiddle and debug, but any information or insight
> would be greatly appreciated. Thank you.
>
> Sincerely,
> Tony Leguía
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

Hi Chengrong,
I believe this work was done before Jikes RVM became publically
available and the source code was never made available.
Mike
_____________________________________________________________
Michael Hind, Senior Manager, Programming Technologies Department
IBM T.J. Watson Research Center
http://www.research.ibm.com/people/h/hind
914 784-7589
"史成荣" <icyrong@...>
Sent by: jikesrvm-researchers-bounces@...
07/11/2008 02:18 AM
Please respond to
"General discussion of Jikes RVM design, implementation, issues, and
plans" <jikesrvm-researchers@...>
To
"jikesrvm-researchers" <jikesrvm-researchers@...>
cc
Subject
[rvm-research] (no subject)
hi all,
I am interested in Datarace Detection and want to have a deep look at the
work 'Efficient and Precise Datarace Detection for Multithreaded
Object-Oriented Programs' by Jong-Deok Choi, Keunwoo Lee, Alexey
Loginov....
How can I get the source code of this work? Can some one give me the
patch?
Thanks,
Chengrong
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

Hello all,
I'm having a bit of a problem with a GC I wrote. When I attempt to run the rvm with my GC I get a conflicting virtual space request error.
It is the following:
Conflicting virtual address request for space "immortal" at 0x70000000
Key: (I)mmortal (N)onmoving (D)iscontiguous (E)xtent (F)raction
HEAP_START 0x60000000
AVAILABLE_START 0x65800000
boot IN 0x60000000->0x6fffffff E 0x10000000
immortal IND []
meta ND []
los ND []
plos N 0xaac00000->0xafffffff F 0.07
sanity ND []
non-moving ND []
sm-code ND []
lg-code ND []
myGC-space 0x70000000->0x9cbfffff F 0.60
AVAILABLE_END 0xb0000000
HEAP_END 0xb0000000
exiting
It seems the immortal space is being set to the same region as myGC-space. But, I am unsure why this would occur. Is it because I am requesting too big a region for myGC-space? I was thinking of explicitly declaring what part of virtual memory I would like for my space so that perhaps immortal space and myGC-space would not coincide, but I feel like this would be a hack and not an actual solution to my problem.
I will continue to fiddle and debug, but any information or insight would be greatly appreciated. Thank you.
Sincerely,
Tony Leguía

hi all,
I am interested in Datarace Detection and want to have a deep look at the work 'Efficient and Precise Datarace Detection for Multithreaded Object-Oriented Programs' by Jong-Deok Choi, Keunwoo Lee, Alexey Loginov....
How can I get the source code of this work? Can some one give me the patch?
Thanks,
Chengrong