harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Date Wed, 16 Aug 2006 21:12:37 GMT
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

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


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

View raw message