Skip to main content

Green Thread in CVM?

6 replies [Last post]
max_mu
Offline
Joined: 2006-11-15

Hi Gurus,
I think Green Thread is one of the most important feature of CLDC-HI, which reduces porting effort dramatically, but why it's still not available in CVM?phoneMEAdvanced is designed to run on some "hi-end" devices, such as smartphone or DigiTV etc.; the "advanced" devices in today's market, however, usually don't have "advanced" OS (e.g Linux). Thus CVM's native threads model is always the most risky part of porting work. Even though some OS provide sort of thread facilities, they still appear non-consistent behavior to Linux/WM, which makes Java applications sometimes work on Linux/WM but not on other platform. According to my experience, in a non-Linux/WM porting project, there's always over 50% of working time spends on native thread related issues.
So my question is: what's the purpose of not implementing Green Thread in CVM? Is it possible to be implemented in future CVM?

Thanks,
M@x

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
xyzzy (Dean)

If you want to use Green Threads to meet the requirements of the porting
layer on your desired platform, then I don't think there is anything
preventing you from doing that. The right choice depends on the
platform. For example, does the platform provide non-blocking I/O
and network calls? What happens when native code calls a function that
blocks for a long time?

phonemeadvanced@mobileandembedded.org wrote:
> Hi Gurus,
> I think Green Thread is one of the most important feature of CLDC-HI, which reduces porting effort dramatically, but why it's still not available in CVM?phoneMEAdvanced is designed to run on some "hi-end" devices, such as smartphone or DigiTV etc.; the "advanced" devices in today's market, however, usually don't have "advanced" OS (e.g Linux). Thus CVM's native threads model is always the most risky part of porting work. Even though some OS provide sort of thread facilities, they still appear non-consistent behavior to Linux/WM, which makes Java applications sometimes work on Linux/WM but not on other platform. According to my experience, in a non-Linux/WM porting project, there's always over 50% of working time spends on native thread related issues.
> So my question is: what's the purpose of not implementing Green Thread in CVM? Is it possible to be implemented in future CVM?
>
> Thanks,
> M@x
> [Message sent by forum member 'max_mu' (max_mu)]
>
> http://forums.java.net/jive/thread.jspa?messageID=253555
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

nsicom100
Offline
Joined: 2007-04-30

Green threads will require some tuning inside the CVM. Working with green threads leads to working with a polling machine, and because one must guarantee that each thread does not consume more time than some timeslice, explicit thread-switches will have to be inserted at not a few points in the code.

There are more advantages to green threads than ease of porting. Inter-thread locks can be removed if a polling machine is used. This generally improves efficiency dramatically and should not be forgotten.

The negative side of green threads is not as insurmountable as might seem. In NSIcom's CrE-ME Virtual Machine even user-defined native methods can be blocking, even though this Virtual Machine runs green threads throughout.

xyzzy
Offline
Joined: 2006-08-30

The original JDK and PersonalJava had something called "Green threads", but it was different from the CLDC model. "Green threads" used timer interrupts to trigger
context switches, so explicit polling points were not required. But blocking native
code was a problem. For example, all calls to malloc() had to use the
JVM's malloc that was wrapped in a Green Thread mutex.

I agree that supporting the CLDC threading model in CVM would be a useful feature,
but nobody has contributed that code yet.

Dean

nsicom100
Offline
Joined: 2007-04-30

The best way of operating green threads is through polling. A polling machine makes execution deterministic, and eliminates multi-threading instabilities caused by a lock or mutex that was forgotten. Moreover, with no locks the code runs faster, and that alone should have been a reason for having it in CVM. But (my) experience shows that there is another reason that surpasses all, and even applies if you would never want to actually deploy a polling-based Virtual Machine: The determinism of a polling machine is a truly huge asset for debugging the code!

max_mu
Offline
Joined: 2006-11-15

Thanks a lot for the answers.
phoneMEFeature's CLDC has a good implementation of non-polling Green Thread, while a "Deterministic" option can be used for special debugging requirement, which acts VM in sort of deterministic fashion. It also provides SNI mechanism to resolve long-wait native calling issue, such as I/O operations, if platform can support asynchronous interfaces for these operations. So I personally prefer phoneMEFeature's thread model. I agree the problem now is nobody contribute the code to implement it on CVM. Where can I find some good documents for threading system implementation, which other than the code itself in phoneMEFeature?

nsicom100
Offline
Joined: 2007-04-30