harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Date Fri, 18 Aug 2006 13:19:32 GMT
> 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.
Except the performance, are there any reasons why we may need to keep
the fields like "gc_private_data" in the thread block?


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

Thanks,
Andrey.

On 8/17/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> Windows uses ia32 segment register fs:14 for fast thread-local storage
> access.  I think Linux somehow uses the gs segment register.  Assuming
> we would like to access thread-local memory from vmmagic, below is a
> first stab at a design.  The intention is to not disrupt existing
> vmmagic design and also keep things as clear and type-safe as
> possible.
>
> Add the following new classes to vmmagic:
>
> public class SegmentRegister
> { /*intentionally empty*/ }
> public final class SegmentRegisterFS extends SegmentRegister
> {/*intentionally empty*/ }
> public final class SegmentRegisterGS extends SegmentRegister
> {/*intentionally empty*/ }
>
> Add a few new methods to vmmagic Address class:
>
> public int loadInt(SegmentRegister segReg);
> public long loadLong(SegmentRegsiter segReg);
>
> public void store(int value, SegmentRegister segReg);
> public void store(long value, SegmentRegister segReg);
>
> Some sample Java code to see how the above would work in real life:
>
> Address addr = Address.fromInt(0x14);
>
> SegmentRegisterFS  segFs = new SegmentRegisterFS();
>
> int tlsPtr = addr.loadInt(segFs);
>
> /*
> Thinking about how a "C" jvm like DRLVM is constructed, tlsPtr would
> be pointing at a C data struct.  Let's assume the following layout for
> the C data struct
>
> 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...
> }
> */
>
> /*
> The JIT (or GC) would access their thread-local storage area via Java
> code as follows
> */
>
> Address addr2 = Address.fromInt(tlsPtr);
> Offset ofs = Offset.fromInt(0x38);
> //read jit_private_data[0]
> int privateData = addr2.loadInt(ofs);
> //read jit_private_data[1]
> ofs = ofs.plus(0x4);
> int privateData = addr2.loadInt(ofs);
>
>
> ---------------- end of code example
>
> 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.
>
> Comments?
>
> --
> 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
>
>


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


Mime
View raw message