harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Date Fri, 18 Aug 2006 16:33:22 GMT
On 8/18/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
> > struct jvm_thread_block {
> >  char * name of thread;
> >  lock_t current_lock_held;
> >  status current_state_of_thread;
> >  blah, blah, blah...
> >  int jit_private_data[16];  //assume this is offset 0x38 from start of
> > jvm_thread_block
> >  int gc_private_data[16];
> >  blah, blah, blah...
> > }
> Another way to store GC or JIT specific data in thread blocks could be:
> // In GC code - store GC data
> int gc_key = VMThreadMgr.tlsAlloc();
> VMThreadMgr.tlsSet(gc_key,  gcDataBlockAddr);
> // Retirive GC data:
> VMThreadMgr.tlsGet(gc_key);
> In this case, GC or JIT don't have to be aware of the internal
> structure of a thread block.

I like the above idea.  If the JIT really can make the above fast, I
would like to use it to associate MMTk thread specific objects to
DRLVM's thread-local data struct. To be clear, there is the issue of
compiling VMThreadMgr.tlsGet(key); with the C compiler and also with
the JIT.  Optimistically, the JIT can replace this call with a
"vmmagic-like" intrinsic.  The JIT will need to be able to call a
JIT/VM api during compile to learn the address arithmetic needed to
materialize the fs:14 pointer to "key" in DRLVM's thread struct.

Compiling the above with the C compiler is a different story.  We
can't hack on the C compiler to include VM specific intrinsics.  There
may be cases in C code where you need to get to thread local storage
quickly and have to revert to using __asm {mov eax, fs:[14];.......}

> Except the performance, are there any reasons why we may need to keep
> the fields like "gc_private_data" in the thread block?
I know I will need to stuff MMTk's thread specific collection and
allocation objects in the gc_private_data area.   Then pull them out
quickly at runtime.  While this job could be done using an ugly hack,
it would be best with straight forward integration into DRLVM.  I will
send more MMTk/DRLVM design integration details within a week.  I am
actively working on this area right now.

> > Of course, the offset into the JVM data struct is fragile and an edit
> > of the JVM thread block's header file could cause nasty surprises.  On
> > the other hand, this data struct does not change very often.  In
> > practice, it should not be any greater risk than what C header files
> > already impose on software engineering.
> I think the problem is that C/C++ isn't the only language which is
> defacto used in drlvm. JIT encoder internal API, lil, asm are the
> examples of other languages.

I would really like to see lil disappear.  Ideally, all asm is
generated by the JIT.  Even if we have to drop down to using the code
emitter to generate the asm, it should always be the domain of the
JIT.  Thus either write in Java  w/ vmmagic or JIT emitted asm or
somewhere between the two (class file annotations, ugly bytecode

>Java/vmmagic may probably join this set
> as well. As a result, it may be very difficult to intercept every
> instance of access to the internals of a thread structure in case
> there will be a need to change it.
> On the other hand, I guess the bugs which can be caused by the misuse
> of the thread block are not the ones which can be easily identified...

OK.  I agree.  I volunteer to help clean up this code.  But it will
have to happen after MMTk and GCV5 are on track.

> Thanks,
> Andrey.

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

View raw message