Fast method dispatch and effective use of primitives for reified generics in managed X10

Takeuchi, Mikio; Zakirov, Salikh; Kawachiya, Kiyokuni; Onodera, Tamiya

doi:10.1145/2246056.2246060

Cited by 5 publications

(6 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To manifest this semantic gap in generics, Managed X10 represents Java generic types as raw types and eliminates type parameters at source code level. For more detailed discussions, please refer to [15,16].…”

Section: Constructors Constructors Of Java Types Are Seen As Construcmentioning

confidence: 99%

“…For those who are interested in the implementation of generics in Managed X10, please consult [16]. We also do not cover function types, function values, and all non-static methods.…”

Section: Linking Java To X10mentioning

confidence: 99%

“…This is kind of optimization for the implementation of covariant method override while preserving the ability for passing and returning Java primitives without boxing. For details, please refer to our paper [16].…”

Section: Linking Java To X10mentioning

confidence: 99%

“…To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. reified generics like C++ templates made the efficient execution of X10 programs on Java platform require novel implementation techniques that were described in [15,16] (distributed GC is described in [8]), and complicated the interoperation with existing Java code.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Java interoperability in managed X10

Takeuchi

Cunningham

Grove

et al. 2013

Proceedings of the Third ACM SIGPLAN X10 Workshop

Self Cite

View full text Add to dashboard Cite

The ability to smoothly interoperate with other programming languages is an essential feature to reduce the barriers to adoption for new languages such as X10. Compiler-supported interoperability between Managed X10 and Java was initially previewed in X10 version 2.2.2 and is now fully supported in X10 version 2.3. In this paper we describe and motivate the Java interoperability features of Managed X10. For calling Java from X10, external linkage for Java code is explained. For calling X10 from Java, the current implementation of Java code generation is explained.An unusual aspect of X10 is that, unlike most other JVM-hosted languages, X10 is also implemented via compilation to C++ (Native X10). The requirement to support multiple execution platforms results in unique challenges to the design of cross-language interoperability. In particular, we discovered that a single top exception type that covers all exception types from source and all target languages is needed as a native type of the source language for portable exception handling. This realization motivated both minor changes in the X10 language specification and an extensive redesign of the X10 core class library for X10 2.3.

show abstract

Section: Constructors Constructors Of Java Types Are Seen As Construcmentioning

confidence: 99%

“…For those who are interested in the implementation of generics in Managed X10, please consult [16]. We also do not cover function types, function values, and all non-static methods.…”

Section: Linking Java To X10mentioning

confidence: 99%

Section: Linking Java To X10mentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Java interoperability in managed X10

Takeuchi

Cunningham

Grove

et al. 2013

Proceedings of the Third ACM SIGPLAN X10 Workshop

Self Cite

View full text Add to dashboard Cite

show abstract

“…However, since we control rewiring and do it in a conservative fashion, we only use the type tags available, thus miniboxing does not need any mechanism for type argument lifting. This paper has systematically avoided the problem of name mangling, which has been discussed in the context of Scala [13] and more recently of X10 [40]. Finally, miniboxing is not limited to classes and methods, but could also be used to reduce bytecode in specialized translations of random code blocks in the program [39].…”

Section: Related Workmentioning

confidence: 99%

Miniboxing

Ureche

Talau

Odersky

2013

Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Programming Systems Languages &Amp; Application

View full text Add to dashboard Cite

Parametric polymorphism enables code reuse and type safety. Underneath the uniform interface exposed to programmers, however, its low level implementation has to cope with inherently non-uniform data: value types of different sizes and semantics (bytes, integers, floating point numbers) and reference types (pointers to heap objects). On the Java Virtual Machine, parametric polymorphism is currently translated to bytecode using two competing approaches: homogeneous and heterogeneous. Homogeneous translation requires boxing, and thus introduces indirect access delays. Heterogeneous translation duplicates and adapts code for each value type individually, producing more bytecode. Therefore bytecode speed and size are at odds with each other. This paper proposes a novel translation that significantly reduces the bytecode size without affecting the execution speed. The key insight is that larger value types (such as integers) can hold smaller ones (such as bytes) thus reducing the duplication necessary in heterogeneous translations. In our implementation, on the Scala compiler, we encode all primitive value types in long integers. The resulting bytecode approaches the performance of monomorphic code, matches the performance of the heterogeneous translation and obtains speedups of up to 22x over the homogeneous translation, all with modest increases in size.

show abstract