On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
