db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott hutinger <...@www.mprojects.Horrabin.wiu.edu>
Subject Re: Lock-free and wait-free concurrency
Date Sat, 30 Apr 2005 04:02:07 GMT
Jeremy Boynes wrote:

> David Van Couvering wrote:
>
>> I was looking to see if "++" was atomic (as I suspected it's not) and 
>> I found this very interesting article from the Blue Guys about 
>> java.util.concurrent.atomic in JDK 1.5.  I am not an expert in 
>> locking, but this looked very interesting.  Has anybody looked at 
>> this?  Could Derby take advantage of this?
>>
>> http://www-106.ibm.com/developerworks/java/library/j-jtp11234/
>>
>> David
>
>
> I think there is a lot of stuff in j.u.concurrent that Derby could 
> use, if only we could get a 1.5 version going ;-)
>
> With the 1.1 J2ME profiles that support the 1.4 APIs now in PFD 
> perhaps we should look at the platform roadmap going forward. Perhaps 
> a split would be appropriate between a platform for embedded devices 
> (based on CDC 1.1 and JSR-169) with little concurrent access and 
> limited resources and multi-user standalone/J2EE servers (based on 
> 1.5) optimized for high concurrent access with unconstrained resources.
>
> -- 
> Jeremy
>
(just an alternative view of things (fluff))

I was just thinking about this whole thing based on the VM versions/J2ME 
etc.  I was a bit worried about what complexities are induced by moving 
forward and keeping older code from getting bit-rot etc.  A big portion 
of this is related to architectures that are not supported in some type 
of easy to download VM.  Currently Derby is running without problems on 
a Zaurus C3000 (4gig hard drive); although somewhat low on resources, I 
wouldn't call it starved.  But, most of the embedded devices are of a 
processor nature that are not fully supported by some of the larger 
'units' in the industry.  But J2ME solves a lot of those problems.

I hate to harp on the subject, but getting newer alternative processor 
VM's up and running are person resource dependent with the newer vm's 
past 1.3.  Now, what are the differences between J2ME and a 
non-hotspot/jit VM of 1.3.x?  I say anything that has a jit or hotspot 
starts to take over anything else.  Although if one is resource lean, 
then what are the trade-offs for the jit?  Smart jit, major jit, jit 
hotspots, jit what?  (J2ME looks like it has some nice controls on fine 
tuning this). The line here is getting to the point of what can people 
currently get  for a VM on a strange processor that people can really 
use now.

I diverge (normal).  The point of all this is I don't have a clue about 
the architecture of Derby.  It needs to move forward without too many 
constraints on backward compatibility.  But from the other point of 
view, it's nice to have a code base still intact that older VM's can use.

BTW, the article is nice; but I thought atomic was all that existed in 
the world :-)

I haven't followed the complete thought processes of how older VM's are 
going to reach EOL (end of life cycle).  Perhaps the xbox will create 
some handhelds that are ppc related...  It would be nice to have a bit 
more facts on J2ME/derby/jitted methods/ and resource needs etc.  But 
that would be a future project.

scott



Mime
View raw message