English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Tools annual

Global: Zendy Free Plan

Global: Zendy Tools monthly

Global: Zendy Plus monthly

This paper presents our experience with building a cross-domain object invocation mechanism that is conscious about memory usage. Cross-domain object invocation issues are very similar to cross-domain procedure call issues. Although the cross-domain procedure call performance issues have been discussed widely, there is very little reference to issues regarding space. It is a typical example of a case where the issues arising in practice are more complicated than the ones described in the reference literature. Our mechanism is discussed in terms of the Spring modular operating system, but the same principles are applicable to other operating systems. The Spring system is a distributed computing environment running on a networked collection of computers. Each individual Spring system is based around a microkernel known as the nucleus. The nucleus is structured to support fast and secure cross address-space object invocations. Most of the traditional operating system services are provided by servers running as user-mode domains. In a system such as Spring, fast, secure, and space-efficient cross-domain invocation is extremely important. Argument buffers are used to pass data from one process to another. For fast cross addressspace procedure calls the maximum size of this buffer should accommodate a small number of page frames. In typical contemporary architectures this size varies between 5 and 10K. In a system such as Spring, where there is a large number of active calls, this size leads to excessive memory usage. Earlier measurements have shown that at run-time the marshalled form of the arguments of most of the calls is less than a hundred bytes. Copying page size objects is the only notable exception. Our implementation uses small 128 byte buffers by default. A very fast mechanism is used to extend the small buffer for calls with marshaled arguments that do not fit in the small buffer. Therefore, it is very space efficient and does not affect the overall system performance. Measurements from our implementation that support these claims are presented.

Buffer Management Issues in the Implementation of Fast Interprocess Communication