[DRLVM/MMTk] jitrino.jet write barrier and vmmagic

[Weldon Washburn <we...@gmail.com>]

On 7/18/06, Alex Astapchuk <al...@gmail.com> wrote:
> Weldon,
>
> I've updated the magics.cpp to reflect the changes in MMTk:
>
> - add/sub replaced with plus/minus
> - fixed constants passed to MMTk's WB code wrt
> org.mmtk.utility.Constants.*WRITE_BARRIER
> - Stub implementation of atomic attempt() (always succeeds currently)
> - Stub (no-op) implementation for prepare*() and prefetch()
> - changed rsha/rshl impl wrt Robin Garner's clarification

Thanks. I picked up the new magics.cpp file and built and ran
test.java.  The test.java seems to work fine.

>
> I attached new magics.cpp the the same JIRA issue -
> http://issues.apache.org/jira/browse/HARMONY-816
> I had no chance to test new functionality properly.
>
> I believe there must be a test suite for at least unboxed/*
> things. Does anybody knows if it really exists ?

I have been looking for such thing but did not find it.  I plan to
write a "SimplePointerArithmetic.java" to see how well the compiler
intrinsics work.  Once the basics are tested, I will focus on making
NoGC actually allocate some objects by hard code calls to
MutatorContext.alloc(...);  Once alloc(...) works, perhaps you can
modify Jitrino.JET to call MutatorContext.alloc(...) whenever an
"object new" happens.  Since we are doing bringup in single thread
only, we can simply not make MutatorContext part of the OS/Java thread
context.  Just use a global static to access the MutatorContext
object.  My initial code will look something like:

        static MutatorContext mc = new MutatorContext(); // or something like it

        while(true) {
            Object obj1 = mc.alloc(16, 0, 0, NoGC.ALLOC_DEFAULT, 0);
            // use vmmagic to patch up the object header so it
            // is a legitimate DLRVM object
        }

The above should (quickly) run out of heap, crash and burn.  Once it
crashes because it ran out of memory, we can work on the jitrino.jet
object allocaction code.

>
>
> p.s.
> I though new file with the same name replaces/obsoletes previous one,
> but it does not. So, currently there are 2 magics.cpp in the JIRA issue.
> Please don't be confused by it. The proper one is the latest:
> http://issues.apache.org/jira/secure/attachment/12337096/magics.cpp.
> This new magics.cpp replaces previous one completely (no need to
> merge/whatever).
>
> Btw, I did not find a way to remove previos file. Did I overlooked
> something ?
> I don't think creating new JIRAs is a good solution, but I also don't
> want to overflow the single issue with several files with the same name
> (I expect more magics.cpp to come).
> What is the best strategy to manage it?

Please let's keep all the versions of magics.cpp in one JIRA.  What
you are doing is perfect for now.  Its even harder to search the
entire JIRA database for the latest version of magics.cpp.  At least
on my web browser, it shows the older version(s) in a dim grey font.
If it gets to be a real bother, I can probably login to JIRA and throw
away ancient versions.
>
>
> --
> Thanks,
>   Alex
>
>

---------------------------------------------------------------------
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