Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstrom. Flick: A flexible, optimizing IDL compiler. In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, pages 44-- 56, Las Vegas, NV, June 1997.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....the request, the client blocks until the results become available. Reducing the number of system elements A large number of generated IDL stubs and skeletons increase the overhead of routing invocations to object implementations. Compiler optimization techniques can alleviate the problem [Eid97] but they cannot eliminate it completely. Several possibilities exist for reducing the number of interfaces, operations, and attributes in CORBA based applications. For example, an interface can offer two generic operations, get and set, for supporting access to any number of attributes [Mow97] ....

Eide, E., Frei, K., Ford, B., Lepreau, J., Lindstrom, G., Flick: A Flexible, Optimizing IDL Compiler, In: Proceedings of the ACM SIGPLAN '97 Conference on Programming Language Design and Implementation (PLDI'97), Las Vegas, Nevada, June 1997, 44-56.

....buffer manipulation routines can then be optimized away. Generating call site specific marshaling as described in this paper is in part an application of partial evaluation. The compiler s information about the arguments to a remote call is used to specialize the code to serialize objects. Flick [7] is a flexible and optimizing IDL compiler: it compiles a remote interface to a set of skeletons and stubs for a given language. An important feature of Flick is that it also optimizes the generated stubs and skeletons much as a normal compiler would. In our implementation the stubs and skeletons ....

Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstrom. Flick: A Flexible, Optimizing IDL Compiler. In Proceedings of the 1997.

....and adaptable way than on producing efficient stubs. In fact, stub code performance was negligible for early microkernels that required multiple thousands of cycles per ipc. However, with high performance ipc, stub code efficiency becomes an issue. For example, when using the Flick IDL compiler [2] for the SawMill Linux file system [3] we found that the generated user level stub code consumed about 340 instructions (approximately 170 cycles) per read request. When reading a 4K block from the file system, the stub code adds an overhead of about 7 . For an industrial system, such overheads ....

....of Linux based components that provide typical system services such as file systems and network systems and general components such as memory, task, device, and access control managers which enable the composition of a coherent Linux system. 2. 3 Flick IDL Compilers such as Flick [2] can relatively easy be ported to a new OS or middleware kernel and permit extensions through new data types. The output of an IDL compiler is typically used as input for the general purpose compiler, e.g. gcc, that the programmer uses for code development. Easy adaptation of the IDL compiler to ....

Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstorm. Flick: A flexible, optimizing idl compiler. Proceedings of the ACM SIGPLAN '97 Conference on Programming Language Design and Implementation (PLDI), pages 44--56, June 1997.

....with performance requirements of the target domain. Traditional compilation techniques are applicable to DSLs. In fact, DSL features can even enable drastic optimizations, not possible in a GPL, and lead to better performance than equivalent programs written in a generalpurpose language [8]. An hybrid approach may be used in specific cases, as advocated by Thibault et al. 25] This approach relies on program specialization to remove the overhead incurred by the use of an interpreter [16] The idea is to customize the interpreter for a given DSL program. Interestingly, ....

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom. Flick: A flexible, optimizing IDL compiler. In Proceedings of the ACM SIGPLAN '97 Conference on 8 Programming Language Design and Implementation, pages 44--56, Las Vegas, NV, USA, June 15--18, 1997.

....on top of the L4 kernel and a set of services that enable these servers to obtain and manage resources in user mode. Some of the servers consist of Linux 2.2.5 code. Therefore, SawMill provides a Linux kernel environment emulation to run these servers. SawMill uses the ick IDL compiler [EFLL97] to control the L4 system calls. This includes communication. A big problem is to nd the correct boundaries and interfaces of the components, and how to split shared data structures. The boundaries and interfaces of SawMill s servers and their components are not clear. This leads to design ....

E. Eide, B. Frei, J. Lepreau, and G. Lindstrom. Flick: A exible, optimizing idl compiler. In ACM SIGPLAN Conference on 67 Programming Language Design and Implementation. University of Utah, Department of Computer Science, 1997.

....out the importance of a small memory footprint for embedded systems. The interpretive stubs generated by their TAO IDL compiler achieve comparable performance to hand crafted compiled stubs (75 100 ) at a relative code size of only 26 45 . On the other hand, speed oriented IDL compilers like Flick [10] have demonstrated impressive performance with compiled stubs and aggressive inlining. Hoschka and Huitema have suggested a hybrid approach [21] where the decision between compiled and interpretive is based on estimated cost and subsequent solving of a Knapsack like combination problem. ....

....attributes, e.g. for changing allocation semantics or for choosing between alternate transfer mechanisms. 3 TARGET PLATFORM Combining multiple optimizations To build a general, high performance RPC system, a single optimization technique is not sufficient; thus, many newer IDL compilers (e.g. [10, 15]) combine a variety of those techniques. Ford et al. 11] pointed out that the task of making many optimizations work together has become more challenging than simply finding them. 3 Target Platform In this work, our approach is to maximize stub code performance by specializing it to the ....

[Article contains additional citation context not shown here]

Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstrom. Flick: a flexible, optimizing IDL compiler. In Proceedings of the 1997.

....of this feature other than for debugging. 8.3 RPC In the realm of RPC, we are not aware of a system that is highly similar to SRPC. Most recent work in this area concentrates on increasing the performance or flexibility of the RPC substrate, or reducing code size of automatically generated stubs [14, 20, 34]. An excellent example is found in the work on Flick, a flexible infrastructure for building an optimizing RPC layer [14] The main goal of Flick is to separate efficient stub generation from both the specific interface definition language (IDL) and underlying communication layer. Our work on ....

.... Most recent work in this area concentrates on increasing the performance or flexibility of the RPC substrate, or reducing code size of automatically generated stubs [14, 20, 34] An excellent example is found in the work on Flick, a flexible infrastructure for building an optimizing RPC layer [14]. The main goal of Flick is to separate efficient stub generation from both the specific interface definition language (IDL) and underlying communication layer. Our work on Scriptable RPC could likely be extended into the Flick framework. 9. CONCLUSIONS Given current technology trends, we expect ....

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom. Flick: A Flexible, Optimizing IDL Compiler. In PLDI '97, Las Vegas, NV, June 1997.

....is capable of simultaneously measuring the influence of the ORB, the operating system and the underlying network on the performance of CORBA objects. Studies have also been conducted on IDL compiler optimizations that can improve overall performance of the ORB. One such effort is the Flick project[4]. It is claimed that Flick generated stubs marshal data between 2 and 17 times faster than stubs produced by traditional IDL compilers, resulting in an increased end toend throughput by factors between 1.2 and 3.7. While clearly addressing an important topic, the Flick work also clearly ....

Eide, E., Frei, K., Ford, B., Lepreau J. and Lindstorm, G. Flick: A Flexible, Optimizing IDL Compiler. In ACM SIGPLAN'97 Conference on Programming Language Design and Implementation, June 1997.

....and ActualObjects on the server side. This section illustrates a few example optimizations from the catalog (Sect. 4) Optimizing Memory Usage. We use the type information for arguments, results, and Requests (Sect. 4.5) to optimize memory usage. Other memory usage optimizations (Sect. 4. 6)[11,8] are as follows. Client stubs use stack allocation of CallDatas if argument sizes are known at compile time and invocation is synchronous. Avoid dynamic allocation, Sect. 4.6. Single threaded ClientCallTasks(andServiceTasks) reuse the same CallData instance across a sequence of calls. ....

Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstrom. Flick: A flexible, optimizing IDL compiler. In ACM SIGPLAN '97 Conference on Programming Language Design and Implementation (PLDI), pages 44--56, June 1997. 151

....the possibility of errors. Domain specific languages have recently found considerable interest in the systems programming community. Recent examples include instruction set description languages [22, 3] an interface description language for remote procedure call stub generation and optimization [11], and a specification language for automatically generating network packet filters [21] 7 Conclusion: Implications for Domain Specific Languages for Systems Software It would be gratuitous to reiterate the successes and shortcomings of Teapot. Instead, we present some generalized insight ....

Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstrom. Flick: A Flexible, Optimizing IDL Compiler. In ACM SIGPLAN Conference on Programming Language Design and Implementation, Las Vegas, Las Vegas, Nevada, June 1997.

....available on the web, and discussions with device driver experts for Windows, Linux and embedded operating systems. The overall result of our domain analysis shows that a language is needed to provide a high level software interface to hardware devices. As is usually the case for interfaces [10, 11], our language should have a declarative nature. 4.2. Levels of abstractions The top level of a Devil specification is the declaration of a device. Physical addresses, abstracted as ports or ranges of ports, parameterize the declaration. Ports then allow device registers to be declared. Finally, ....

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom. Flick: A flexible, optimizing IDL compiler. In Proceedings of the ACM SIGPLAN '97 Conference on Programming Language Design and Implementation, pages 44--56, Las Vegas, NV, USA, June 15--18, 1997.

....overheads, in particular context switches overheads, are minimized. Second, we have seen marked improvements in memory management approaches that enable zero copy protocols (e.g. fbufs [6] and emulated copy [3] Other advances include, improved kernel modularity [9] component model services [7], multiserver security protocols, etc. Note that we are not the only researchers who believe it is time to re examine multiservers, as a multiserver system is also being constructed on the Pebble kernel [10] In addition, there is a greater need for multiserver architectures now. Consider the ....

....need to obtain the page from its memory server, and so on. Similar resource faulting approaches are also used for obtaining access control data, names, tasks, and mount points. Other ubiquitous libraries provide multiserver specific functionality, such as Flick s cross domain procedure call stubs [7] and synchronization. 4 SawMill Protocols In order to build an efficient multiserver, system protocols must designed to minimize IPC frequency and overhead (see Section 2.3) We identify these principles for designing efficient multiserver protocols: ffl Make system calls directly to the ....

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom. Flick: A flexible, optimizing IDL compiler. In Proc. PLDI'97, 1997.

....overheads, in particular context switches overheads, are minimized. Second, we have seen marked improvements in memory management approaches that enable zero copy protocols (e.g. fbufs [5] and emulated copy [3] Other advances include, improved kernel modularity [7] component model services [8], multiserver security protocols, etc. Note that we are not the only researchers who believe it is time to re examine multiservers, as a multiserver system is also being constructed on the Pebble kernel [11] In addition, there is a greater need for multiserver Faculty of Informatics, ....

....to obtain the page from its dataspace manager, and so on. Similar resource faulting approaches are also used for obtaining access control data, names, tasks, and mount points. Other ubiquitous libraries provide multiserver speci c functionality, such as Flick s cross domain procedure call stubs [8] and synchronization. Page 3 4 SawMill Protocols In order to build an ecient multiserver, system protocols must designed to minimize IPC frequency and overhead (see Section 2.3) We identify these principles for designing ecient multiserver protocols: Make system calls directly to the ....

[Article contains additional citation context not shown here]

E. Eide et al. Flick : A exible, optimizing IDL compiler. In PLDI'97. ACM, June 1997.

....adaptable way than on producing efficient stubs. In fact, stub code performance was insignificant for early microkernels that required multiple thousands of cycles per IPC. However, with high performance IPC, stub code efficiency becomes an issue. For example, when using the Flick IDL compiler [4] for the SawMill Linux file system [5] we found that the generated user level stub code consumed about 260 instructions per read request. When reading a 4K block from the file system, the stub code adds an overhead of about 17 due to stub instructions. The stub code may also generates further ....

....system services through multiple user level servers, such as file systems, device drivers and network systems. Further general components such as memory servers, task servers, and access control managers enable the composition of a coherent Linux system. 2. 3 Flick IDL Compilers such as Flick [4] are relatively easy to port to a new OS or middleware kernel, and they are extensible through new data types. The output of an IDL compiler is typically used as input for a general purpose compiler, e.g. gcc, that a programmer uses for code development. Easy adaptation of the IDL compiler to new ....

Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstorm. Flick: A flexible, optimizing idl compiler. Proceedings of the ACM SIGPLAN '97 Conference on Programming Language Design and Implementation (PLDI), pages 44--56, June 1997.

....of the underlying communication mechanism to optimize argument marshaling. Furthermore, we allow the user to in uence the code generation process with additional meta information about involved components. This work is motivated by experiences we gained using an existing IDL compiler (Flick [3]) to build a Multiserver File System on top of the L4 microkernel [12] 2 Towards fast IDL systems One of the rst projects to deal with the problem of building a fast IDL system was Flick by the University of Utah [3] Its aim is to build a highly exible IDL compiler which can be used with ....

.... is motivated by experiences we gained using an existing IDL compiler (Flick [3] to build a Multiserver File System on top of the L4 microkernel [12] 2 Towards fast IDL systems One of the rst projects to deal with the problem of building a fast IDL system was Flick by the University of Utah [3]. Its aim is to build a highly exible IDL compiler which can be used with various IDL types as well as generate code for di erent communication platforms. One of its major ideas to improve the performance of the argument marshaling is to enable the native language compiler (i.e. the C compiler) ....

Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstrom. Flick: A Flexible, Optimizing IDL Compiler. In Proceedings of the Conference on Programming Language Design and Implementation (PLDI), 1997. 2 The overhead is caused mainly by a more complex setup of the copy operation in the kernel.

....such as multithreaded ORB [6] high performance and real time ORB [11, 14] optimized IDL Proceedings of the 8th International Conference on High Performance Computing and Networks, pp. 668 677, LNCS 1823, Springer Verlag, Amsterdam, May, 2000 (Interface Definition Language) compiler [2], and environment sensitive event delivery mechanism [13] Besides, there is some research that focus on making the component framework layer suitable for parallel computing to facilitate extending parallel computing over wide area networks. In general, this is achieved by implementing the ....

....implementation. Data dispatching overhead is reduced by communicating through port in DoHPC. 6 Related Works Much research has been carried out to optimize the underlying layer of distributed object architecture, such as improving the efficiency of current distributed object s communication [6, 2], extending the real time and QoS features [11, 14] and supporting the mobile environment in a distributed object framework [13] Some frameworks support the composition of parallel component, such as LSA [3] POOMA [10] PARDIS [8] etc. DoHPC differs Multi threaded ORB in two aspects. Firstly, ....

E. Eide, K. Frei et.al, Flick: A Flexible, Optimizing IDL Compiler, ACM SIGPLAN Notices, Vol. 32, No. 5, May 1997.

....di#erent data models, query interfaces, or views. cawom generated wrappers actually mediate between di#erent execution environments one based on corba, and the other on ASCII command streams. There has been quite a bit of work on enhancing IDLs to introduce additional functionality. Flick [7] is a modular IDL compiler supporting multiple IDLs and language mappings. Flick s modular design lends it for use in custom IDL languages and code generation; thus allowing wrapper code to be generated as part of the product of an IDL compiler. Sterne et al. [25] embed DTEL (domain type ....

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom. Flick: A flexible, optimizing idl compiler. In ACM SIGPLAN PLDI, 1997.

....improving robustness, a DSL can also be used to expose information that can trigger domainspecific optimizations. For example, a parameter passed across layers need not be copied if the language guarantees that a policy only reads it; such optimizations are performed by the Flick IDL compiler [4]. Finally, our experience has shown that the restricted nature of DSLs drastically improves the development time of compilers, reduces the number of concepts to treat, and enables the production of high quality code. Our DSLs. Our approach has been carried out in practice on two families of ....

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom. Flick: A flexible, optimizing IDL compiler. In Proceedings of the ACM SIGPLAN '97 Conference on Programming Language Design and Implementation, pages 44--56, Las Vegas, NV, USA, June 15--18, 1997.

....and adaptable way than on producing efficient stubs. In fact, stub code performance was negligible for early microkernels that required multiple thousands of cycles per IPC. However, with high performance IPC, stub code efficiency becomes an issue. For example, when using the Flick IDL compiler [2] for the SawMill Linux file system [3] we found that the generated user level stub code consumed about 340 instructions (approximately 170 cycles) per read request. When reading a 4K block from the file system, the stub code adds an overhead of about 7 . For an industrial system, such overheads ....

....of Linux based components that provide typical system services such as file systems and network systems and general components such as memory, task, device, and access control managers which enable the composition of a coherent Linux system. 2. 3 Flick IDL compilers such as Flick [2] are relatively easy to port to a new OS or middleware kernel and permit extensions through new data types. The output of an IDL compiler is typically used as input for the general purpose compiler such as gcc that the programmer uses for code development. Easy adaptation of the IDL compiler to ....

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstorm. Flick: A flexible, optimizing idl compiler. Proceedings of the ACM SIGPLAN '97 Conference on Programming Language Design and Implementation (PLDI), pages 44--56, June 1997.

No context found.

Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstrom. Flick: A flexible, optimizing IDL compiler. In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, pages 44-- 56, Las Vegas, NV, June 1997.

....export. For more complicated cases, in which every wrapper must tailored to a specific use, we intend to incorporate a flexible code generation scheme into Knit, so that Knit can create the implementations and unit definitions for the wrappers. Our previous experience with a flexible stub compiler [4] will be useful in this area. 5 Conclusion Knit is a new component definition and linking language, designed to handle the manifest and nonmanifest aspects of systems and middleware code. Component composition in Knit acts like aspect weaving, and future improvements to Knit will increase ....

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom. Flick: A flexible, optimizing IDL compiler. In Proc. ACM SIGPLAN '97 Conf. on Programming Language Design and Implementation (PLDI), pages 44--56, Las Vegas, NV, June 1997.

....demanding requirements of high performance distributed applications, not only in terms of performance, but also in terms of support for complex programming models and communication patterns. To explore the design and use of such middleware, we have implemented Flick, the Flexible IDL Compiler Kit [9]. Flick provides a unique framework for experimenting with new IDL compilation techniques, and we are using Flick to develop new strategies for producing IDL based stubs that meet the needs of sophisticated distributed applications. As an initial experiment in this area, we chose to generate ....

....of message data in order to produce efficient marshaling and unmarshaling code. For example, a Flick generated stub may use memcpy to copy an object if Flick is able to determine that no byte swapping or other presentation layer data transformations are required. Previously reported experiments [9] demonstrate that Flickgenerated stubs can marshal data between 2 and 17 times as fast as equivalent stubs generated by other IDL compilers. The reduction in presentation layer overhead results in significant end to end throughput improvements for communicating applications. Because Flick is both ....

[Article contains additional citation context not shown here]

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom. Flick: A flexible, optimizing IDL compiler. In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, pages 44--56, Las Vegas, NV, June 1997. 15

....types to be used throughout a project, both for computation and for intercomponent communication, at the expense of limiting a project to a single language. This limitation can be unacceptable when integrating information systems that are already implemented in multiple languages. IDL compilers [13, 15, 17, 18, 19, 22, 24] support multiple languages by generating stubs from IDL. However, IDL compilers also generate programming language data declarations from the IDL that must be used for intercomponent communication. These imposed types are rarely what the programmer would have chosen for computational purposes. ....

....of isomorphisms than PolySpinner, particularly ones involving non abstract constructed types such as unions, arrays, and objects with public instance variables. In addition, Mockingbird adapters are network enabled and do not require recompilation of components. Some IDL compilers, such as Flick [13], are more flexible than others. Flick has relaxed the strict one for one mapping that characterizes most such tools. The flexibility provided in Flick is, however, more limited. It accepts several IDLs as inputs, but an IDL declaration is still the only declaration used in stub generation. It ....

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom. Flick: A flexible, optimizing IDL compiler. In SIGPLAN 1997 Conference on Programming Language Design and Implementation. ACM, June 1997. 14

No context found.

E. Eide, K. Frei, B. Ford, J. Lepreau, and G. Lindstrom. Flick: A flexible, optimizing IDL compiler. In Proceedings of the ACM SIGPLAN '97 Conference on Programming Language Design and Implementation, pages 44--56, Las Vegas, NV, USA, June 1997.

No context found.

Eric Eide, Kevin Frei, Bryan Ford, Jay Lepreau, and Gary Lindstorm. Flick: A flexible, optimizing idl compiler. Proceedings of the ACM SIGPLAN '97 Conference on Programming Language Design and Implementation (PLDI), pages 44--56, June 1997.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC