etosch
commented
12 years ago I'm going to write some loosely connected statements to make sure I understand everything correctly. Since I promised to post within the hour, this is incomplete. I'll be editing, but I wanted to get it into the pipeline first (haw haw), since I'm not terribly effective at the superscalar thing (haw haw).
We have a notion of threads inside the VM. This is our Thread.js
Java has its own Thread object, which has certain features. When a user program creates a new Thread, this is done in a variety of ways. Regardless of implementation, the call to start the thread is located in the Runnable interface.
This Java Thread class needs to be intercepted by our machine, much like calls to Class or Object. This will be implemented in a new file called invoke.js
I'm using the term "intercept" to denote the case where the invoke call would defer to the kinds things currently implemented as "hacks." I chose the term because we are intercepting them before they get to the vanilla invoke handler.
We would need to ensure that the following subtasks (not listed in any particular order) are completed:
- Define a predicate to determine whether something ought to be run as a thread on our VM. This could be something as simple as checking whether the method name is
runand whether the method implementsRunnable. While Threads can also be created by subclassingThread,Threadalso implements Runnable, so we're probably fine just checking forRunnable. - All instance fields of the Thread are thread-local. This is already ensured by
new-instance. Static fields, as with any class, are shared amongst all Threads. We shouldn't need any special "hardware" for this. - The tutorial page toggles between tasks using a random number of milliseconds for execution. Our current implementation has us doing a round-robin thing. I'm assuming that these are two different scheduling algos. Do we want to hold off on the random toggling for now? I kind of not-so-secretly want to implement cool scheduling algos, or I don't know, exponential backoff! But back on planet earth - Javascript's random number generator : do we need it? If so, is it good enough for our purposes? Also on this note, if the java.util.Random library is often used, do we want to be calling the javascript native random stuff or the java library? Also, shall we just ignore thread priority for now?
- The start instance method on java's Thread corresponds to adding our javascript Thread to the list of _threads on the VM.
- Add a
statefield to the Thread object, corresponding to the State inner class of Java's Thread. Write corresponding intercepts for valueOf and values - ThreadGroup can be handled by changing the VM's _threads data structure from an array to a tree
- interrupting a thread - will this even do anything for the round-robin scheduler? Behavior is determined by the scheduling algo.
- activeCount should be straightforward. Consider maintaining an active count field in the VM that threads can modify, rather than querying threads, since the latter implementation could (a) cause inconsistency and (b) have high latency.
- checkAccess - is there a flag in the dex file that indicates this? Or do we infer from the tree in VM (e.g. I can access me, my parents can access me).
- currentThread - this should be straightforward; pull from VM
- dumpStack - ignore
- enumerate - straightforward
- everything related to stack traces - ignore
- (get|set)ContextClassLoader - this harkens back to an earlier question I had about ClassLibrary. Are we going to ignore this or should we return a ClassLibrary? It seems analogous to ClassLibrary, but it looks like multiple ClassLoaders on the JVM might be permitted? Is this true for dalvik?
- regarding ids - I guess this means we need to add a uid to the Threads. This can be done with a generator/gensym-type-thing in the global.js file.
- (get|set)UncaughtExceptionHandler - not sure what opcodes this will call...
- holdsLock - will need to implement the monitor calls. This might not be sent to invoke.
- new states to add to our javascript Thread, will be called via getters and setters (we should be able to compress these into a single condition if we use RegExps wisely) : state, contextClassLoader/ClassLibrary?, id, name, priority, threadGroup,
Do we handle deprecated functions? Testing: Threads can be made in the following ways, so we ought to test each:
- Implementing
Runnableas a named class - Implementing
Runnableas an anonymous class - Sublassing
Threadas a named class - Subclassing
Threadas an anonymous class? Each of these with each of the overloaded options (or maybe the maximal supersets)?
Are we going to want to implement Exceptions first?
jjfiv
Some reading material on Threads in Java
I was remembering incorrectly;
run()is on a user subclass ofRunnable, not ofThreadso we'll need to do that.We'll probably need hooks inside of
new-instanceto manufacture our own "synthetic" Thread objects, and we'll need hooks in invoke to catch all the methods...I think maybe the best way to be doing these things is to have a flag on methods that let us know if the implementation is in javascript, and a function attached to it rather than icode to execute. This would allow our hacks within invoke to be small, and allow us to define objects elsewhere in javascript? Maybe this would just move the hacks to
new-instance...So this is a design/find subtasks sort of challenge. Let me know if I can help.