You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/07/24 03:23:44 UTC

[DRLVM/MMTk] v0.1 porting layer has been committed

All,

Implementations of the abstract classes from:
http://cs.anu.edu.au/~Steve.Blackburn/private/mmtk-20060714.jar :::
src/org/mmtk/vm/*.java  have been created.

They are svn commited at:
drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk/*.java

The ant build.xml has been modified to build the new "ext" directory
as well as a modified "test.java"

You should be able to download the mmtk-20060714.jar from above.  Then
overlay the newly committed svn files.  Then type "ant" to create the
MMTk and test class files.

To run the test class, first build jitrino.jet with the write barrier
mods, then type:

......\drlvm\trunk\build\win_ia32_msvc_debug\deploy\jre\bin\ij.exe -Xb
ootclasspath/p:.;mmtk.jar -Xem jet: -Xjit jet::wb4j %1 test

You should see:

org.apache.HarmonyDRLVM.mm.mmtk.ObjectModel
org.apache.HarmonyDRLVM.mm.mmtk.ReferenceGlue.getReferencesAreObjects()
was called
org.apache.HarmonyDRLVM.mm.mmtk.Memory.getAvailableStartConstant(),
needs fixing now
org.apache.HarmonyDRLVM.mm.mmtk.Memory.getAvailableEndConstant(),
needs fixing now
top of test wjw------
test0 - ok
test1 - ok
test2 - ok
testWB - seems ok

The above "...was called" and "...needs fixing" are stubbed out MMTk
methods that are invoked when, "VM vm_init = new VM();" in test.java
is executed.  My next step is to work on the stubs so that NoGC will
run properly.

I also recently discovered what could be problem with jitrino.JET
compiling OPCODE_LCMP.  Jitrino.JET is core dumping.  This problem
occurs when attempting to compile a method that uses vmmagic
functions.  More details shortly.  Below is a stack trace of where the
JIT runs into problems:

 	jitrino.dll!_assert(const char * expr=0x01068098, const char *
filename=0x01068060, unsigned int lineno=0x0000094d)  Line 295	C
>	jitrino.dll!Jitrino::Jet::Compiler::gen_stack_to_args(bool pop=true,
unsigned int num=0x00000002, const Jitrino::Jet::jtype *
args=0x01068620)  Line 2381 + 0x4a	C++
 	jitrino.dll!Jitrino::Jet::Compiler::gen_x_cmp(JavaByteCodes
op=OPCODE_LCMP, Jitrino::Jet::jtype jt=i64)  Line 2026	C++
 	jitrino.dll!Jitrino::Jet::Compiler::handle_ik_a(const
Jitrino::Jet::JInst & jinst={...})  Line 152	C++
 	jitrino.dll!Jitrino::Jet::Compiler::handle_inst(const
Jitrino::Jet::JInst & jinst={...})  Line 93	C++
 	jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
pc=0x0000000e, Jitrino::Jet::BBState * prev=0x05d8bbd4, unsigned int
jsr_lead=0xffffffff)  Line 601	C++
 	jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
pc=0x0000000d, Jitrino::Jet::BBState * prev=0x05d8bd74, unsigned int
jsr_lead=0xffffffff)  Line 661	C++
 	jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
pc=0x00000000, Jitrino::Jet::BBState * prev=0x00000000, unsigned int
jsr_lead=0xffffffff)  Line 651	C++
 	jitrino.dll!Jitrino::Jet::Compiler::compile(void * ch=0x05d8eb4c,
Method * method=0x058fdf08)  Line 239	C++
 	jitrino.dll!Jitrino::Jet::compile_with_params(void *
jit_handle=0x00b41518, void * ch=0x05d8eb4c, Method *
method=0x058fdf08, OpenMethodExecutionParams params={...})  Line 233 +
0x13	C++
 	jitrino.dll!JIT_compile_method_with_params(void * jit=0x00b41518,
void * compilation=0x05d8eb4c, Method * method_handle=0x058fdf08,
OpenMethodExecutionParams compilation_params={...})  Line 255 +
0x15	C++
-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [DRLVM/MMTk] v0.1 porting layer has been committed

Posted by Weldon Washburn <we...@gmail.com>.
On 7/25/06, Alex Astapchuk <al...@gmail.com> wrote:
> Weldon,
>
> I've updated the magics.cpp with fromLong/toLong fixed.
>
> But I suspect other issues as well, and I'm working on it, so
> please expect more commits of magics.cpp to come.

Please reserve the word "commit" to refer to an svn commit.  Otherwise
everyone will be confused.  To be clear, magics.cpp has been posted to
JIRA Harmony-816.  It has not been commited to svn repository.

In any case, I got the new magics.cpp and it seems the "long" problem
has been fixed.

>
> --
> Thanks,
>   Alex
>
> Alex Astapchuk wrote:
> > Weldon,
> >
> >  > I also recently discovered what could be problem with jitrino.JET
> >  > compiling OPCODE_LCMP.  Jitrino.JET is core dumping.  This problem
> > I'm looking into the issue.
> > Could you please share the class/method that causes assertion ?
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [DRLVM/MMTk] v0.1 porting layer has been committed

Posted by Alex Astapchuk <al...@gmail.com>.
Weldon,

I've updated the magics.cpp with fromLong/toLong fixed.

But I suspect other issues as well, and I'm working on it, so
please expect more commits of magics.cpp to come.

-- 
Thanks,
   Alex

Alex Astapchuk wrote:
> Weldon,
> 
>  > I also recently discovered what could be problem with jitrino.JET
>  > compiling OPCODE_LCMP.  Jitrino.JET is core dumping.  This problem
> I'm looking into the issue.
> Could you please share the class/method that causes assertion ?
> 
> 




---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [DRLVM/MMTk] v0.1 porting layer has been committed

Posted by Alex Astapchuk <al...@gmail.com>.
Weldon,

 > I also recently discovered what could be problem with jitrino.JET
 > compiling OPCODE_LCMP.  Jitrino.JET is core dumping.  This problem
I'm looking into the issue.
Could you please share the class/method that causes assertion ?


-- 
Thanks,
   Alex

Weldon Washburn wrote:
> All,
> 
> Implementations of the abstract classes from:
> http://cs.anu.edu.au/~Steve.Blackburn/private/mmtk-20060714.jar :::
> src/org/mmtk/vm/*.java  have been created.
> 
> They are svn commited at:
> drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk/*.java 
> 
> 
> The ant build.xml has been modified to build the new "ext" directory
> as well as a modified "test.java"
> 
> You should be able to download the mmtk-20060714.jar from above.  Then
> overlay the newly committed svn files.  Then type "ant" to create the
> MMTk and test class files.
> 
> To run the test class, first build jitrino.jet with the write barrier
> mods, then type:
> 
> .......\drlvm\trunk\build\win_ia32_msvc_debug\deploy\jre\bin\ij.exe -Xb
> ootclasspath/p:.;mmtk.jar -Xem jet: -Xjit jet::wb4j %1 test
> 
> You should see:
> 
> org.apache.HarmonyDRLVM.mm.mmtk.ObjectModel
> org.apache.HarmonyDRLVM.mm.mmtk.ReferenceGlue.getReferencesAreObjects()
> was called
> org.apache.HarmonyDRLVM.mm.mmtk.Memory.getAvailableStartConstant(),
> needs fixing now
> org.apache.HarmonyDRLVM.mm.mmtk.Memory.getAvailableEndConstant(),
> needs fixing now
> top of test wjw------
> test0 - ok
> test1 - ok
> test2 - ok
> testWB - seems ok
> 
> The above "...was called" and "...needs fixing" are stubbed out MMTk
> methods that are invoked when, "VM vm_init = new VM();" in test.java
> is executed.  My next step is to work on the stubs so that NoGC will
> run properly.
> 
> I also recently discovered what could be problem with jitrino.JET
> compiling OPCODE_LCMP.  Jitrino.JET is core dumping.  This problem
> occurs when attempting to compile a method that uses vmmagic
> functions.  More details shortly.  Below is a stack trace of where the
> JIT runs into problems:
> 
>     jitrino.dll!_assert(const char * expr=0x01068098, const char *
> filename=0x01068060, unsigned int lineno=0x0000094d)  Line 295    C
>>     jitrino.dll!Jitrino::Jet::Compiler::gen_stack_to_args(bool pop=true,
> unsigned int num=0x00000002, const Jitrino::Jet::jtype *
> args=0x01068620)  Line 2381 + 0x4a    C++
>     jitrino.dll!Jitrino::Jet::Compiler::gen_x_cmp(JavaByteCodes
> op=OPCODE_LCMP, Jitrino::Jet::jtype jt=i64)  Line 2026    C++
>     jitrino.dll!Jitrino::Jet::Compiler::handle_ik_a(const
> Jitrino::Jet::JInst & jinst={...})  Line 152    C++
>     jitrino.dll!Jitrino::Jet::Compiler::handle_inst(const
> Jitrino::Jet::JInst & jinst={...})  Line 93    C++
>     jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
> pc=0x0000000e, Jitrino::Jet::BBState * prev=0x05d8bbd4, unsigned int
> jsr_lead=0xffffffff)  Line 601    C++
>     jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
> pc=0x0000000d, Jitrino::Jet::BBState * prev=0x05d8bd74, unsigned int
> jsr_lead=0xffffffff)  Line 661    C++
>     jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
> pc=0x00000000, Jitrino::Jet::BBState * prev=0x00000000, unsigned int
> jsr_lead=0xffffffff)  Line 651    C++
>     jitrino.dll!Jitrino::Jet::Compiler::compile(void * ch=0x05d8eb4c,
> Method * method=0x058fdf08)  Line 239    C++
>     jitrino.dll!Jitrino::Jet::compile_with_params(void *
> jit_handle=0x00b41518, void * ch=0x05d8eb4c, Method *
> method=0x058fdf08, OpenMethodExecutionParams params={...})  Line 233 +
> 0x13    C++
>     jitrino.dll!JIT_compile_method_with_params(void * jit=0x00b41518,
> void * compilation=0x05d8eb4c, Method * method_handle=0x058fdf08,
> OpenMethodExecutionParams compilation_params={...})  Line 255 +
> 0x15    C++


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [DRLVM/MMTk] v0.1 porting layer has been committed

Posted by Weldon Washburn <we...@gmail.com>.
On 7/24/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Weldon Washburn wrote:
> > On 7/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
> >> Are you up-to-date?  We don't have "ij.exe" anymore...

I just did a clean svn checkout and now can build "java.exe".

> > Actually, I tried several times over the weekend to do a fresh, new
> > "svn checkout".  I rolled back to a two week old revision.  classlib
> > and drlvm downloaded OK but I get the following compile time error:
> >
> >    [javac]
> > C:\t_harmony\classlib\trunk\modules\auth\src\main\java\windows\org\a
> > pache\harmony\auth\module\NTLoginModule.java:43:
> > org.apache.harmony.auth.module.
> > NTLoginModule is not abstract and does not override abstract method
> > initialize(j
> > avax.security.auth.Subject,javax.security.auth.callback.CallbackHandler,java.uti
> >
> > l.Map<java.lang.String,?>,java.util.Map<java.lang.String,?>) in
> > javax.security.a
> > uth.spi.LoginModule
> >    [javac] public class NTLoginModule implements LoginModule {
> >
> > Since the svn commits don't interact with the build at this point, I
> > went back to a two week old tree to demo the MMTk porting bugs.
> >
> > This brings up a point.  What should we do when we discover an svn
> > checkout and build is broken?
>
> I'm not convinced it's broken.  I've been building just fine all weekend
>  to create the JRE and HDK downloads, so I think that it's local to your
> box.

It is local to my box afterall.  It took a while but I discovered I
was using an old beta version of J2SE 1.5.

>
> We get broken build messages on the commit list from IBM (and we need to
>  add that feature to our build-test infra so other can do that)
>
>
> > I figure I would wait until Monday to
> > retry.  If it is still broken, then start looking at the logs.
> > Perhaps we should post a "[classlib] revision 9999999 is broken
> > message" with the problem in the body of the message??
>
> Try a fresh checkout and see what happens.
>
> geir
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [DRLVM/MMTk] v0.1 porting layer has been committed

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Weldon Washburn wrote:
> On 7/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:

>> Are you up-to-date?  We don't have "ij.exe" anymore...
> Actually, I tried several times over the weekend to do a fresh, new
> "svn checkout".  I rolled back to a two week old revision.  classlib
> and drlvm downloaded OK but I get the following compile time error:
> 
>    [javac]
> C:\t_harmony\classlib\trunk\modules\auth\src\main\java\windows\org\a
> pache\harmony\auth\module\NTLoginModule.java:43:
> org.apache.harmony.auth.module.
> NTLoginModule is not abstract and does not override abstract method
> initialize(j
> avax.security.auth.Subject,javax.security.auth.callback.CallbackHandler,java.uti
> 
> l.Map<java.lang.String,?>,java.util.Map<java.lang.String,?>) in
> javax.security.a
> uth.spi.LoginModule
>    [javac] public class NTLoginModule implements LoginModule {
> 
> Since the svn commits don't interact with the build at this point, I
> went back to a two week old tree to demo the MMTk porting bugs.
> 
> This brings up a point.  What should we do when we discover an svn
> checkout and build is broken?  

I'm not convinced it's broken.  I've been building just fine all weekend
 to create the JRE and HDK downloads, so I think that it's local to your
box.

We get broken build messages on the commit list from IBM (and we need to
 add that feature to our build-test infra so other can do that)


> I figure I would wait until Monday to
> retry.  If it is still broken, then start looking at the logs.
> Perhaps we should post a "[classlib] revision 9999999 is broken
> message" with the problem in the body of the message??

Try a fresh checkout and see what happens.

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [DRLVM/MMTk] v0.1 porting layer has been committed

Posted by Weldon Washburn <we...@gmail.com>.
On 7/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Weldon Washburn wrote:
> > All,
> >
> > Implementations of the abstract classes from:
> > http://cs.anu.edu.au/~Steve.Blackburn/private/mmtk-20060714.jar :::
> > src/org/mmtk/vm/*.java  have been created.
>
> This is under CPL, right?
Exactly.  MMTk is under CPL.  The intention is that the porting layer
located in "ext"ernal directory becomes part of the JVM.  Thus Apache
License 2.0 was added to the files yesterday.
>
> >
> > They are svn commited at:
> > drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk/*.java
> >
>
> Cool
>
> >
> > The ant build.xml has been modified to build the new "ext" directory
> > as well as a modified "test.java"
>
> I'm confused.  Which "build.xml"?
Sorry.  This particular build.xml is at: .../drlvm/trunk/vm/MMTk.  I
did not modify drlvm's build... yet.
>
>
> >
> > You should be able to download the mmtk-20060714.jar from above.  Then
> > overlay the newly committed svn files.  Then type "ant" to create the
> > MMTk and test class files.
> >
> > To run the test class, first build jitrino.jet with the write barrier
> > mods, then type:
> >
> > ......\drlvm\trunk\build\win_ia32_msvc_debug\deploy\jre\bin\ij.exe -Xb
> > ootclasspath/p:.;mmtk.jar -Xem jet: -Xjit jet::wb4j %1 test
> >
>
> Are you up-to-date?  We don't have "ij.exe" anymore...
Actually, I tried several times over the weekend to do a fresh, new
"svn checkout".  I rolled back to a two week old revision.  classlib
and drlvm downloaded OK but I get the following compile time error:

    [javac] C:\t_harmony\classlib\trunk\modules\auth\src\main\java\windows\org\a
pache\harmony\auth\module\NTLoginModule.java:43: org.apache.harmony.auth.module.
NTLoginModule is not abstract and does not override abstract method initialize(j
avax.security.auth.Subject,javax.security.auth.callback.CallbackHandler,java.uti
l.Map<java.lang.String,?>,java.util.Map<java.lang.String,?>) in javax.security.a
uth.spi.LoginModule
    [javac] public class NTLoginModule implements LoginModule {

Since the svn commits don't interact with the build at this point, I
went back to a two week old tree to demo the MMTk porting bugs.

This brings up a point.  What should we do when we discover an svn
checkout and build is broken?   I figure I would wait until Monday to
retry.  If it is still broken, then start looking at the logs.
Perhaps we should post a "[classlib] revision 9999999 is broken
message" with the problem in the body of the message??

>
>
> > You should see:
> >
> > org.apache.HarmonyDRLVM.mm.mmtk.ObjectModel
> > org.apache.HarmonyDRLVM.mm.mmtk.ReferenceGlue.getReferencesAreObjects()
> > was called
> > org.apache.HarmonyDRLVM.mm.mmtk.Memory.getAvailableStartConstant(),
> > needs fixing now
> > org.apache.HarmonyDRLVM.mm.mmtk.Memory.getAvailableEndConstant(),
> > needs fixing now
> > top of test wjw------
> > test0 - ok
> > test1 - ok
> > test2 - ok
> > testWB - seems ok
> >
> > The above "...was called" and "...needs fixing" are stubbed out MMTk
> > methods that are invoked when, "VM vm_init = new VM();" in test.java
> > is executed.  My next step is to work on the stubs so that NoGC will
> > run properly.
> >
> > I also recently discovered what could be problem with jitrino.JET
> > compiling OPCODE_LCMP.  Jitrino.JET is core dumping.  This problem
> > occurs when attempting to compile a method that uses vmmagic
> > functions.  More details shortly.  Below is a stack trace of where the
> > JIT runs into problems:
> >
> >     jitrino.dll!_assert(const char * expr=0x01068098, const char *
> > filename=0x01068060, unsigned int lineno=0x0000094d)  Line 295    C
> >>     jitrino.dll!Jitrino::Jet::Compiler::gen_stack_to_args(bool pop=true,
> > unsigned int num=0x00000002, const Jitrino::Jet::jtype *
> > args=0x01068620)  Line 2381 + 0x4a    C++
> >     jitrino.dll!Jitrino::Jet::Compiler::gen_x_cmp(JavaByteCodes
> > op=OPCODE_LCMP, Jitrino::Jet::jtype jt=i64)  Line 2026    C++
> >     jitrino.dll!Jitrino::Jet::Compiler::handle_ik_a(const
> > Jitrino::Jet::JInst & jinst={...})  Line 152    C++
> >     jitrino.dll!Jitrino::Jet::Compiler::handle_inst(const
> > Jitrino::Jet::JInst & jinst={...})  Line 93    C++
> >     jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
> > pc=0x0000000e, Jitrino::Jet::BBState * prev=0x05d8bbd4, unsigned int
> > jsr_lead=0xffffffff)  Line 601    C++
> >     jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
> > pc=0x0000000d, Jitrino::Jet::BBState * prev=0x05d8bd74, unsigned int
> > jsr_lead=0xffffffff)  Line 661    C++
> >     jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
> > pc=0x00000000, Jitrino::Jet::BBState * prev=0x00000000, unsigned int
> > jsr_lead=0xffffffff)  Line 651    C++
> >     jitrino.dll!Jitrino::Jet::Compiler::compile(void * ch=0x05d8eb4c,
> > Method * method=0x058fdf08)  Line 239    C++
> >     jitrino.dll!Jitrino::Jet::compile_with_params(void *
> > jit_handle=0x00b41518, void * ch=0x05d8eb4c, Method *
> > method=0x058fdf08, OpenMethodExecutionParams params={...})  Line 233 +
> > 0x13    C++
> >     jitrino.dll!JIT_compile_method_with_params(void * jit=0x00b41518,
> > void * compilation=0x05d8eb4c, Method * method_handle=0x058fdf08,
> > OpenMethodExecutionParams compilation_params={...})  Line 255 +
> > 0x15    C++
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [DRLVM/MMTk] v0.1 porting layer has been committed

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Weldon Washburn wrote:
> All,
> 
> Implementations of the abstract classes from:
> http://cs.anu.edu.au/~Steve.Blackburn/private/mmtk-20060714.jar :::
> src/org/mmtk/vm/*.java  have been created.

This is under CPL, right?

> 
> They are svn commited at:
> drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk/*.java
>

Cool

> 
> The ant build.xml has been modified to build the new "ext" directory
> as well as a modified "test.java"

I'm confused.  Which "build.xml"?


> 
> You should be able to download the mmtk-20060714.jar from above.  Then
> overlay the newly committed svn files.  Then type "ant" to create the
> MMTk and test class files.
> 
> To run the test class, first build jitrino.jet with the write barrier
> mods, then type:
> 
> ......\drlvm\trunk\build\win_ia32_msvc_debug\deploy\jre\bin\ij.exe -Xb
> ootclasspath/p:.;mmtk.jar -Xem jet: -Xjit jet::wb4j %1 test
>

Are you up-to-date?  We don't have "ij.exe" anymore...


> You should see:
> 
> org.apache.HarmonyDRLVM.mm.mmtk.ObjectModel
> org.apache.HarmonyDRLVM.mm.mmtk.ReferenceGlue.getReferencesAreObjects()
> was called
> org.apache.HarmonyDRLVM.mm.mmtk.Memory.getAvailableStartConstant(),
> needs fixing now
> org.apache.HarmonyDRLVM.mm.mmtk.Memory.getAvailableEndConstant(),
> needs fixing now
> top of test wjw------
> test0 - ok
> test1 - ok
> test2 - ok
> testWB - seems ok
> 
> The above "...was called" and "...needs fixing" are stubbed out MMTk
> methods that are invoked when, "VM vm_init = new VM();" in test.java
> is executed.  My next step is to work on the stubs so that NoGC will
> run properly.
> 
> I also recently discovered what could be problem with jitrino.JET
> compiling OPCODE_LCMP.  Jitrino.JET is core dumping.  This problem
> occurs when attempting to compile a method that uses vmmagic
> functions.  More details shortly.  Below is a stack trace of where the
> JIT runs into problems:
> 
>     jitrino.dll!_assert(const char * expr=0x01068098, const char *
> filename=0x01068060, unsigned int lineno=0x0000094d)  Line 295    C
>>     jitrino.dll!Jitrino::Jet::Compiler::gen_stack_to_args(bool pop=true,
> unsigned int num=0x00000002, const Jitrino::Jet::jtype *
> args=0x01068620)  Line 2381 + 0x4a    C++
>     jitrino.dll!Jitrino::Jet::Compiler::gen_x_cmp(JavaByteCodes
> op=OPCODE_LCMP, Jitrino::Jet::jtype jt=i64)  Line 2026    C++
>     jitrino.dll!Jitrino::Jet::Compiler::handle_ik_a(const
> Jitrino::Jet::JInst & jinst={...})  Line 152    C++
>     jitrino.dll!Jitrino::Jet::Compiler::handle_inst(const
> Jitrino::Jet::JInst & jinst={...})  Line 93    C++
>     jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
> pc=0x0000000e, Jitrino::Jet::BBState * prev=0x05d8bbd4, unsigned int
> jsr_lead=0xffffffff)  Line 601    C++
>     jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
> pc=0x0000000d, Jitrino::Jet::BBState * prev=0x05d8bd74, unsigned int
> jsr_lead=0xffffffff)  Line 661    C++
>     jitrino.dll!Jitrino::Jet::Compiler::bbs_gen_code(unsigned int
> pc=0x00000000, Jitrino::Jet::BBState * prev=0x00000000, unsigned int
> jsr_lead=0xffffffff)  Line 651    C++
>     jitrino.dll!Jitrino::Jet::Compiler::compile(void * ch=0x05d8eb4c,
> Method * method=0x058fdf08)  Line 239    C++
>     jitrino.dll!Jitrino::Jet::compile_with_params(void *
> jit_handle=0x00b41518, void * ch=0x05d8eb4c, Method *
> method=0x058fdf08, OpenMethodExecutionParams params={...})  Line 233 +
> 0x13    C++
>     jitrino.dll!JIT_compile_method_with_params(void * jit=0x00b41518,
> void * compilation=0x05d8eb4c, Method * method_handle=0x058fdf08,
> OpenMethodExecutionParams compilation_params={...})  Line 255 +
> 0x15    C++

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org