From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8cc95983ce7acc64 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-25 00:12:52 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.stealth.net!204.127.161.2.MISMATCH!wn2feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc05-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3B875089.275EDFFC@worldnet.att.net> From: James Rogers X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Commentary on Industry Move to C++ References: <3B859FCD.5FEA40DD@lmtas.lmco.com> <3b85b1fc_1@news3.prserv.net> <3B865C3C.A7569D9A@lmtas.lmco.com> <3B870551.ABBF94E6@worldnet.att.net> <3B874691.65A75825@easystreet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 25 Aug 2001 07:12:50 GMT NNTP-Posting-Host: 12.86.32.22 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 998723570 12.86.32.22 (Sat, 25 Aug 2001 07:12:50 GMT) NNTP-Posting-Date: Sat, 25 Aug 2001 07:12:50 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:12408 Date: 2001-08-25T07:12:50+00:00 List-Id: Al Christians wrote: > > James Rogers wrote: > > > > > > I assume Sun has some reasons for insisting you know not to use Java > > for these purposes. > > > > They say it's because of timing -- ie because of garbage collection > -- they can't make it a sure thing that it will accomplish anything > in a given amount of time. But they also say that it's not an > admission that it's likely to crash or give the wrong answers. > > That's really a JVM issue, not a Java issue -- there are many > languages running on JVM these days. Timing is a JVM issue. It is also a Java issue. My experience is that the Java language in general, and Java standard API classes in particular, are relatively inefficient. Java static data members are allocated on a stack. All other Java non primitive data items are allocated dynamically. Aside from the fact that additional overhead is involved in marking and deallocating dynamic memory, the most common Java programming models allocate a lot of memory when other languages like Ada, C, Basic, Pascal, etc will not need to allocate memory. This addiction to allocation produces performance problems that affect both timing and memory utilization. For instance, using a Java collection, such as a HashMap to store values associated with unique keys requires that all items stored must be instances of classes, not primitive types. How, then, do you store numeric types in a HashMap? Simple. You convert the numeric type to its corresponding wrapper class. The primary reason to use a HashMap is for rapid access to the values contained therein. If you want to total values read from an input stream by key value you will need to increment the values stored in the HashMap. Unfortunately, the numeric wrapper classes are incapable of performing math operations. You must convert the wrapper class object to a primitive type, perform the calculations, then create a new numeric wrapper object and put it in the HashMap under the same key. All this conversion, allocation, and reassignment is expensive. Timing is affected greatly. (Of course, each of those objects must be eventually deallocated or "collected" by the GC, which even if it were deterministic would still have a serious affect on timing.) Java also demonstrates plenty of unpredictability with its thread model. Releasing a thread from a "wait" call is accomplished by having another thread call the "notify" or the "notifyAll" method. The "notify" method causes the virtual machine to release one thread from the wait state. There is no sense of a queue in the "wait" state corresponding to an Ada entry queue. You have no way of knowing which thread will be affected by a "notify" call. It may be one that must immediately return to the "wait" state because its boundary condition has not been satisfied. If so, then you can encounter a deadlock because the expected thread was not activated. The common wisdom is that one should never use "notify". Instead, one should always use "notifyAll". "notifyAll" releases all threads from the "wait" state. This avoids deadlock, because one of the waiting threads will discover a satisfied boundary condition and continue. All other threads will have to return to the "wait" state. This approach avoids deadlocks but produces timing variations, depending on the number of threads in the "wait" state. Java provides no remedy for this timing issue. Jim Rogers Colorado Springs, Colorado USA