On the 0x1EF day of Apache Harmony [EMAIL PROTECTED] wrote: > Pretty much thanks. > > Though I think I am unsure as to what you mean by IRs.... sorry.
IR = Intermediate Representation (a widely used term in compiler design), see http://en.wikipedia.org/wiki/Compiler > On 19 Sep 2006 10:59:49 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > On the 0x1E9 day of Apache Harmony [EMAIL PROTECTED] wrote: > > > Can someone clarify what Jetrnio.JET is please ? > > > > DRLVM has two JIT compilers: > > * Jitrino.OPT -- aggressively optimizing compiler (having two IRs, > > high-level and platform-specific optimizations) > > * Jitrino.JET -- fast JIT (no IR, simple design, fast compilation, > > improves startup time) > > > > does it anser your question? > > > > > On 9/8/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > > > > > > On 9/8/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Weldon, > > > > > I added 'alloc' support to JIRA 816 (magic2.zip file) > > > > > Now it supports objects allocation only, not arrays. MMTk allocation > > > > works > > > > > only for class named 'test' and methods with prefix 'testAlloc'. > > To > > > > turn > > > > > it on use "-Xjit jet::alloc4j" option. > > > > > > > > > > > > Thanks! I will take a look this weekend. > > > > > > > > I had a problem with implementation: usual 'new' vm helper does vtable > > > > field > > > > > initialization in allocated object space by itself. Your alloc() > > method > > > > > doesn't. > > > > > In the patch in JIRA I added vtable initialization code right after > > the > > > > > alloc() call to JIT, that is actually bad design decision (IMO). > > > > > > > > > > > > You are correct. Its bad design. Writing the vtable pointer is not > > the > > > > responsibility of the JIT. MMTk is somewhat vague on who owns vtable > > ptr > > > > init. In any case, it looks like the jit should follow the call to > > > > alloc() > > > > with a call to postAlloc(). I will make sure the postAlloc() code > > fixes > > > > up > > > > the vtable ptr. Its OK to "bend" the typeRef. All I want is the hard > > ptr > > > > that gets written into the object header. We will go back later and > > fix > > > > this interface hack. See below: > > > > > > > > > > > > /** > > > > > > > > * Perform post-allocation actions. For many allocators none are > > > > > > > > * required. > > > > > > > > * > > > > > > > > * @param ref The newly allocated object > > > > > > > > * @param typeRef the type reference for the instance being created > > > > > > > > * @param bytes The size of the space to be allocated (in bytes) > > > > > > > > * @param allocator The allocator number to be used for this allocation > > > > > > > > */ > > > > > > > > public void postAlloc(ObjectReference ref, ObjectReference typeRef, > > > > > > > > int bytes, int allocator) throws InlinePragma { > > > > > > > > > > > > > > > > > > > > > > > > Can we replace the 'alloc()' call with another Java method that uses > > > > > unboxed API and behaves exactly like 'new' helper? > > > > > > > > > > +The test in the patch throws NullPointerException because no memory > > is > > > > > allocated in alloc() now and JET tries to write vtable data by NULL > > > > > address. > > > > > > > > > > > > > > > > > > > > On 9/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > At some point soon we need to go multithread. When can you fix > > the > > > > > > vmmagic > > > > > > atomic operations? > > > > > > > > > > > > > > > > I need one more day to estimate the complexity of this move. > > > > > > > > > > > > > > > -- > > > > > Mikhail Fursov > > > > > > > > > > > > > > > > > > > > > > -- > > > > Weldon Washburn > > > > Intel Middleware Products Division > > > > > > > > > > > > > > > > > -- > > > www.FaeLLe.com > > > www.VikramMohan.com > > > > -- > > Egor Pasko, Intel Managed Runtime Division > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > www.FaeLLe.com > www.VikramMohan.com -- Egor Pasko, Intel Managed Runtime Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
