Right now the MulticoreExpo that's been going on at the Santa Clara Convention Center in California is wrapping up. ARM's John Goodacre, chair of EEMBC Multiprocessing benchmark group, was planning to present a session entitled A technical insight into the EEMBC MP benchmarks that I would have loved to attend.
Here's part of the advance write up
The number of cores will grow exponentially, roughly doubling with each processor generation. Furthermore, chips will exhibit increasingly higher degrees of heterogeneity in terms of cores, interconnect, hardware acceleration, and memory hierarchies. The industry must determine how to efficiently harness this processing capability. The necessity to move beyond parallel computing and SMP paradigms and towards heterogeneous embedded distributed systems will likely drive changes in how embedded software will be created. Thus, it will drive changes into development tools, run-time software, and languages. Programming such systems effectively will require new approaches.
The paper isn't available yet, so I don't know if he talked about Jini and Majc.
MAJC, the Microprocessor Architecture for Java Computing, was the first real multicore CPU. The first silicon, the MAJC-5200, had two cores running at 500Mhz in a fully shared environment with memory controllers, PCI I/O controllers, and a high speed interconnect all on board.
MAJC was as much technology demonstration as real product and is the direct intellectual ancestor to today's UltraSPARC T1 and tomorrow's hardware scout. Unfortunately as salable technology it flubbed, in part because it was well ahead of its time, in part because Sun had no market position in the desktop/home entertainment businesses it was aimed at, but mainly because people at Apple had no interest in working with Sun.
MAJC had a corollary technology: something that had to be invented to open up its markets and which has also proven to have been both ahead of its time and the underlying proof of concept for quite a few successor technologies today.
That something was Jini - and, unlike Majc, it's alive and kicking today. Here's part of Sun's technology overview:
The purpose of the Jini architecture is to federate groups of devices and software components into a single, dynamic distributed system. The resulting federation provides the simplicity of access, ease of administration, and support for sharing that are provided by a large monolithic system while retaining the flexibility, uniform response, and control provided by a personal computer or workstation.The architecture of a single Jini system is targeted to the workgroup. Members of the federation are assumed to agree on basic notions of trust, administration, identification, and policy. It is possible to federate Jini systems themselves for larger organizations.
The most important concept within the Jini architecture is that of a service. A service is an entity that can be used by a person, a program, or another service. A service may be a computation, storage, a communication channel to another user, a software filter, a hardware device, or another user. Two examples of services are printing a document and translating from one word-processor format to some other.
Members of a Jini system federate in order to share access to services. A Jini system should not be thought of as sets of clients and servers, or users and programs, or even programs and files. Instead, a Jini system consists of services that can be collected together for the performance of a particular task. Services may make use of other services, and a client of one service may itself be a service with clients of its own. The dynamic nature of a Jini system enables services to be added or withdrawn from a federation at any time according to demand, need, or the changing requirements of the workgroup using it.
Jini systems provide mechanisms for service construction, lookup, communication, and use in a distributed system. Examples of services include devices such as printers, displays, or disks; software such as applications or utilities; information such as databases and files; and users of the system.
Services in a Jini system communicate with each other by using a service protocol, which is a set of interfaces written in the Java programming language. The set of such protocols is open ended. The base Jini system defines a small number of such protocols which define critical service interactions.
If you take a personal computer running MacOS X today, and connect it to a network with a qualified local printer, the Mac will find that printer, load the appropriate drivers, and make its services available to the user. That's limited network plug and play at work; what Jini and MAJC enabled, and what the embedded folks are working on doing, is extending that capability across larger networks and far more hetergenous devices.