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:26:35 GMT
scott hutinger wrote:

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

One more fluff.  If your going to do any type of 'embedded' type of work 
with something such as derby, then you really need the jit source code, 
plus the rest of the code.  I don't see a jit off-the-shelf giving 
enough information about everything needed (although I very well could 
be wrong, often I am).  Something the size of derby needs to have a 
bunch of 'extra' inclusions of code for getting needed information with 
some possible additions.  Of course, every architecture is different, 
but I think after getting one architecture down with some fairly good 
conclusions on useage, that others could follow (somewhat) closely.  I 
think the useage differences of users also create the need of jit source.

scott

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