379 research outputs found

    Draining the Swamp: Micro Virtual Machines as Solid Foundation for Language Development

    Get PDF
    Many of today\u27s programming languages are broken. Poor performance, lack of features and hard-to-reason-about semantics can cost dearly in software maintenance and inefficient execution. The problem is only getting worse with programming languages proliferating and hardware becoming more complicated. An important reason for this brokenness is that much of language design is implementation-driven. The difficulties in implementation and insufficient understanding of concepts bake bad designs into the language itself. Concurrency, architectural details and garbage collection are three fundamental concerns that contribute much to the complexities of implementing managed languages. We propose the micro virtual machine, a thin abstraction designed specifically to relieve implementers of managed languages of the most fundamental implementation challenges that currently impede good design. The micro virtual machine targets abstractions over memory (garbage collection), architecture (compiler backend), and concurrency. We motivate the micro virtual machine and give an account of the design and initial experience of a concrete instance, which we call Mu, built over a two year period. Our goal is to remove an important barrier to performant and semantically sound managed language design and implementation

    Recycling the Optimized Machine Codes Generated by JavaScript Engine

    Get PDF
    ํ•™์œ„๋…ผ๋ฌธ (์„์‚ฌ)-- ์„œ์šธ๋Œ€ํ•™๊ต ๋Œ€ํ•™์› ๊ณต๊ณผ๋Œ€ํ•™ ์ „๊ธฐยท์ •๋ณด๊ณตํ•™๋ถ€, 2017. 8. ๋ฌธ์ˆ˜๋ฌต.์ž๋ฐ”์Šคํฌ๋ฆฝํŠธ์˜ ์—ญํ• ์ด ๊ณ„์†ํ•ด์„œ ์ฆ๋Œ€๋˜๊ณ  ์žˆ์œผ๋ฉฐ, ์ž๋ฐ”์Šคํฌ๋ฆฝํŠธ ์—”์ง„์˜ ์„ฑ๋Šฅ์ด ์ค‘์š”ํ•œ ์ด์Šˆ๊ฐ€ ๋˜๊ณ  ์žˆ๋‹ค. ๋ณธ ๋…ผ๋ฌธ์€ ์ž๋ฐ”์Šคํฌ๋ฆฝํŠธ ์—”์ง„์˜ ์„ฑ๋Šฅ์„ ํ–ฅ์ƒํ•˜๊ธฐ ์œ„ํ•œ ๋ฐฉ๋ฒ•์œผ๋กœ ๋‹ค๋‹จ๊ณ„(multi-tiered) JIT ์ปดํŒŒ์ผ ์—”์ง„์—์„œ ์ตœ์ ํ™” JIT ์ปดํŒŒ์ผ๋Ÿฌ๊ฐ€ ์ƒ์„ฑํ•˜๋Š” ๊ธฐ๊ณ„์–ด ์ฝ”๋“œ๋ฅผ ์žฌํ™œ์šฉํ•˜๋Š” ๋ฐฉ์‹์„ ์ œ์•ˆํ•œ๋‹ค. ์ด ๋ฐฉ์‹์—์„œ๋Š” ์ตœ์ ํ™” JIT ์ปดํŒŒ์ผ๋Ÿฌ๊ฐ€ ์ƒ์„ฑํ•˜๋Š” ๊ธฐ๊ณ„์–ด ์ฝ”๋“œ๋ฅผ ํŒŒ์ผ์— ์ €์žฅํ•˜์˜€๋‹ค๊ฐ€ ๋‹ค์Œ ํ”„๋กœ๊ทธ๋žจ ์ˆ˜ํ–‰์—์„œ ์ด๋ฅผ ์žฌ์‚ฌ์šฉํ•œ๋‹ค. ๊ทธ๋ฆฌํ•˜์—ฌ ์—”์ง„์—์„œ ์ปดํŒŒ์ผ ์˜ค๋ฒ„ํ—ค๋“œ๋ฅผ ์ œ๊ฑฐํ•˜๊ณ  ์‹œ์ž‘๋ถ€ํ„ฐ ์–‘์งˆ์˜ ์ฝ”๋“œ๋ฅผ ์‚ฌ์šฉํ•˜๊ฒŒ ๋งŒ๋“ ๋‹ค. ๊ธฐ๊ณ„์–ด ์ฝ”๋“œ๋ฅผ ์žฌ์‚ฌ์šฉํ•˜๊ธฐ ์œ„ํ•ด์„œ๋Š” ์ฝ”๋“œ ๋‚ด์˜ ํฌ์ธํ„ฐ๋“ค์„ ํ˜„์žฌ ์ˆ˜ํ–‰์— ๋งž๊ฒŒ ํŒจ์น˜ ํ•ด์ฃผ์–ด์•ผ ํ•˜๋Š”๋ฐ, ์ด๋ฅผ ์œ„ํ•˜์—ฌ ๊ธฐ๊ณ„์–ด ์ฝ”๋“œ์™€ ํ•จ๊ป˜ ์ฝ”๋“œ ๋‚ด์˜ ํฌ์ธํ„ฐ ์œ„์น˜ ๋ฐ ํฌ์ธํ„ฐ๊ฐ€ ๊ฐ€๋ฆฌํ‚ค๋Š” ๊ฐ์ฒด์˜ ์ •์ฒด๋ฅผ ๊ฐ™์ด ์ €์žฅํ•˜๋Š” ํ…Œ์ด๋ธ”์„ ์ƒ์„ฑ, ์ €์žฅํ•œ๋‹ค. ์ตœ์ ํ™” JIT ์ปดํŒŒ์ผ๋Ÿฌ์—์„œ๋Š” ๋ฒ ์ด์Šค๋ผ์ธ JIT ์—์„œ์™€๋Š” ๋‹ฌ๋ฆฌ ์™„์„ฑ๋œ ํ…Œ์ด๋ธ”์„ ๋งŒ๋“ค๊ธฐ ์œ„ํ•ด ์ตœ์ ํ™” ๊ณผ์ • ์ค‘์—์„œ ํŒŒ์ƒ์ ์œผ๋กœ ์ƒ์„ฑ๋˜๋Š” ํฌ์ธํ„ฐ์™€ ํ”„๋กœํŒŒ์ผ์— ์˜ํ•ด ๊ณ ์ • ์ƒ์„ฑ๋˜๋Š” ํฌ์ธํ„ฐ๋“ค๊นŒ์ง€ ์ฐพ์•„์„œ ์ฒ˜๋ฆฌํ•ด์•ผ ํ•œ๋‹ค. ์ „์ž๋Š” ์ตœ์ ํ™” ๊ณผ์ •์„ ๊ฐ™์ด ๋”ฐ๋ผ๊ฐ€๋ฉด์„œ, ํ›„์ž๋Š” ์ปดํŒŒ์ผ๋Ÿฌ๊ฐ€ ํฌ์ธํ„ฐ๋ฅผ ๊ณ ์ • ์ƒ์„ฑํ•˜์ง€ ๋ชปํ•˜๋„๋ก ๋ฐ”๊พธ์–ด ์ฒ˜๋ฆฌํ•œ๋‹ค. ์ด๋ฅผ ์‹ค์ œ ์ž๋ฐ”์Šคํฌ๋ฆฝํŠธ ์—”์ง„ ์ค‘์˜ ํ•˜๋‚˜์ธ JavaScriptCore ์—”์ง„์—์„œ ์ ์šฉํ•œ ๊ฒฐ๊ณผ, ์‚ฌ์šฉ์ž๊ฐ€ ์„ ํƒ์ ์œผ๋กœ ์ด๋“์ด ๋˜๋Š” ๊ธฐ๊ณ„์–ด ์ฝ”๋“œ๋“ค๋งŒ ์žฌ์‚ฌ์šฉ ํ–ˆ์„ ์‹œ ์ตœ๋Œ€ 29%, ํ‰๊ท  11%์˜ ์„ฑ๋Šฅ ํ–ฅ์ƒ์ด ์žˆ์—ˆ๋‹ค.์ œ 1 ์žฅ ์„œ ๋ก  1 ์ œ 2 ์žฅ ์ž๋ฐ”์Šคํฌ๋ฆฝํŠธ ์—”์ง„์˜ ๊ตฌ์กฐ 3 ์ œ 1 ์ ˆ ์ž๋ฐ”์Šคํฌ๋ฆฝํŠธ ์—”์ง„ 3 ์ œ 2 ์ ˆ ์ตœ์ ํ™” JIT ์ปดํŒŒ์ผ๋Ÿฌ์™€ Profile 5 ์ œ 3 ์ ˆ WebKit์˜ JavaScriptCore 7 ์ œ 3 ์žฅ ์ตœ์ ํ™”๋œ ๊ธฐ๊ณ„์–ด ์ฝ”๋“œ์˜ ์žฌํ™œ์šฉ 8 ์ œ 1 ์ ˆ ๊ฐœ์š” 8 ์ œ 2 ์ ˆ ํฌ์ธํ„ฐ ํŒจ์นญ 9 ์ œ 3 ์ ˆ ์ตœ์ ํ™” ๊ณผ์ •๊ณผ ํฌ์ธํ„ฐ ์ƒ์„ฑ 10 ์ œ 4 ์ ˆ Profile๊ณผ ํฌ์ธํ„ฐ ์ƒ์„ฑ 12 ์ œ 5 ์ ˆ ์„ ํƒ์ ์ธ ์žฌํ™œ์šฉ 14 ์ œ 4 ์žฅ ์‹คํ—˜ ๊ฒฐ๊ณผ ๋ฐ ๋ถ„์„ 16 ์ œ 1 ์ ˆ ์‹คํ–‰ ํ™˜๊ฒฝ 16 ์ œ 2 ์ ˆ ์‹คํ—˜ ๊ฒฐ๊ณผ 16 ์ œ 3 ์ ˆ ๊ด€์ฐฐ ๊ฒฐ๊ณผ 17 ์ œ 5 ์žฅ ๊ฒฐ๋ก  ๋ฐ ํ–ฅํ›„ ์—ฐ๊ตฌ 18 ์ฐธ๊ณ ๋ฌธํ—Œ 19 Abstract 20Maste

    HW-SW co-design techniques for modern programming languages

    Get PDF
    Modern programming languages raise the level of abstraction, hide the details of computer systems from programmers, and provide many convenient features. Such strong abstraction from the details of computer systems with runtime support of many convenient features increases the productivity of programmers. Such benefits, however, come with performance overheads. First, many of modern programming languages use a dynamic type system which incurs overheads of profiling program execution and generating specialized codes in the middle of execution. Second, such specialized codes constantly add overheads of dynamic type checks. Third, most of modern programming languages use automatic memory management which incurs memory overheads due to metadata and delayed reclamation as well as execution time overheads due to garbage collection operations. This thesis makes three contributions to address the overheads of modern programming languages. First, it describes the enhancements to the compiler of dynamic scripting languages necessary to enable sharing of compilation results across executions. These compilers have been developed with little consideration for reusing optimization efforts across executions since it is considered difficult due to dynamic nature of the languages. As a first step toward enabling the reuse of compilation results of dynamic scripting languages, it focuses on inline caching (IC) which is one of the fundamental optimization techniques for dynamic type systems. Second, it describes a HW-SW co-design technique to further improve IC operations. While the first proposal focuses on expensive IC miss handling during JavaScript initialization, the second proposal accelerates IC hit operations to improve the overall performance. Lastly, it describes how to exploit common sharing patterns of programs to reduce overheads of reference counting for garbage collection. It minimizes atomic operations in reference counting by biasing each object to a specific thread

    ์–ดํ”Œ๋ฆฌ์ผ€์ด์…˜ ๋‹ค์šด๋กœ๋”ฉ ์‹œ์Šคํ…œ์„ ์œ„ํ•œ ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ

    Get PDF
    ํ•™์œ„๋…ผ๋ฌธ (๋ฐ•์‚ฌ)-- ์„œ์šธ๋Œ€ํ•™๊ต ๋Œ€ํ•™์› : ์ „๊ธฐยท์ปดํ“จํ„ฐ๊ณตํ•™๋ถ€, 2014. 8. ๋ฌธ์ˆ˜๋ฌต.์–ดํ”Œ๋ฆฌ์ผ€์ด์…˜(์•ฑ)์„ ๋‹ค์šด๋กœ๋“œ ๋ฐ›์•„์„œ ์ˆ˜ํ–‰ํ•˜๋Š” ์‹œ์Šคํ…œ์€ DTV๋‚˜ ์Šค๋งˆํŠธํฐ์ฒ˜๋Ÿผ ๋Œ€์ค‘์ ์œผ๋กœ ์‚ฌ์šฉ๋˜๊ณ  ์žˆ๋‹ค. ์•ฑ์„ ๋‹ค์šด๋ฐ›์•„์„œ ์‚ฌ์šฉํ•˜๋Š” ์‹œ์Šคํ…œ๋“ค์€ ๊ฐ€์ƒ ๋จธ์‹ ์„ ์ฃผ๋ฅ˜๋กœ ์‚ฌ์šฉํ•˜๊ณ  ์žˆ๋‹ค. ๊ฐ€์ƒ ๋จธ์‹ ์˜ ๊ฐ€์žฅ ํฐ ๋ฌธ์ œ์ ์€ ์ธํ„ฐํ”„๋ฆฌํ„ฐ๋ฅผ ํ†ตํ•œ ์ˆ˜ํ–‰์— ์˜ํ•œ ๋Š๋ฆฐ ์„ฑ๋Šฅ์ด๋ฉฐ, ์ด ์„ฑ๋Šฅ์˜ ํ–ฅ์ƒ์„ ์œ„ํ•ด ์ฃผ๋กœ ์‚ฌ์šฉ๋˜๋Š” ๊ธฐ์ˆ ์ด ์ ์‹œ ์ปดํŒŒ์ผ๋Ÿฌ์ด๋‹ค. ์ ์‹œ ์ปดํŒŒ์ผ๋Ÿฌ๋Š” ๋‹ค์šด๋ฐ›์€ ์•ฑ์˜ ์ˆ˜ํ–‰ ์ค‘์— ๋™์ ์œผ๋กœ ๋จธ์‹  ์ฝ”๋“œ๋กœ ๋ฒˆ์—ญํ•˜์—ฌ ์‚ฌ์šฉํ•˜๋Š” ๊ธฐ๋ฒ•์œผ๋กœ, ๋™์  ์ปดํŒŒ์ผ๋ ˆ์ด์…˜ ์˜ค๋ฒ„ํ—ค๋“œ๋ฅผ ๊ฐ€์ง€๊ฒŒ ๋œ๋‹ค. ์šฐ๋ฆฌ๋Š” ์ด ๋™์  ์ปดํŒŒ์ผ๋ ˆ์ด์…˜ ์˜ค๋ฒ„ํ—ค๋“œ๋ฅผ ์ œ๊ฑฐํ•˜์—ฌ ์„ฑ๋Šฅ์„ ํ–ฅ์ƒ์‹œํ‚ค๋Š” ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ๋ฅผ ์ œ์•ˆํ•˜์˜€๋‹ค. ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ๋Š” ์ ์‹œ ์ปดํŒŒ์ผ๋Ÿฌ๊ฐ€ ์ƒ์„ฑํ•˜๋Š” ๋จธ์‹  ์ฝ”๋“œ๋ฅผ ์•ฑ์˜ ์ข…๋ฃŒ๋  ๋•Œ ์ง€์šฐ์ง€ ์•Š๊ณ  ํŒŒ์ผํ˜•ํƒœ๋กœ ์Šคํ† ๋ฆฌ์ง€์— ์ €์žฅํ•˜์—ฌ ์ดํ›„์— ์•ฑ์ด ๋‹ค์‹œ ์ˆ˜ํ–‰๋  ๋•Œ ์ €์žฅํ•œ ๋จธ์‹  ์ฝ”๋“œ๋ฅผ ์žฌํ™œ์šฉํ•˜์—ฌ ์‚ฌ์šฉํ•จ์œผ๋กœ์จ ๋Ÿฐํƒ€์ž„ ์ปดํŒŒ์ผ๋ ˆ์ด์…˜ ์˜ค๋ฒ„ํ—ค๋“œ๋ฅผ ์ œ๊ฑฐํ•˜๊ฒŒ ๋œ๋‹ค. ์ €์žฅํ•œ ๋จธ์‹  ์ฝ”๋“œ๋ฅผ ์žฌํ™œ์šฉํ•  ๋•Œ ๋จธ์‹  ์ฝ”๋“œ์— ์ธ์ฝ”๋”ฉ๋œ ์ฃผ์†Œ๊ฐ’๋“ค์€ ์œ ํšจํ•˜์ง€ ์•Š๊ธฐ ๋•Œ๋ฌธ์— ๊ฐ€์ƒ ๋จธ์‹ ์˜ ํ˜„์žฌ ๊ฐ’์— ๋งž์ถ”์–ด ๋ณ€๊ฒฝํ•ด์ฃผ๋Š” ์ž‘์—…์ด ํ•„์š”ํ•˜๋‹ค. ์ด ์ž‘์—…์€ ์ฃผ์†Œ ์žฌ๋ฐฐ์น˜์ด๋‹ค. ์ฃผ์†Œ ์žฌ๋ฐฐ์น˜๋Š” ์ €์žฅ๋œ ๋จธ์‹  ์ฝ”๋“œ๋งŒ์œผ๋กœ ์ˆ˜ํ–‰ํ•  ์ˆ˜๊ฐ€ ์—†๊ธฐ ๋•Œ๋ฌธ์— ์ถ”๊ฐ€์ ์ธ ์ •๋ณด๋ฅผ ๋จธ์‹  ์ฝ”๋“œ๋ฅผ ์ €์žฅํ•˜๋Š” ๊ณผ์ •์—์„œ ์ƒ์„ฑํ•˜์—ฌ ํŒŒ์ผ์— ํ•จ๊ป˜ ์ €์žฅํ•ด ์ฃผ์–ด์•ผ ํ•œ๋‹ค. ์ž๋ฐ”์˜ ์ƒ์ˆ˜ ํ’€ ํ•ด์„์€ ์ฃผ์†Œ ์žฌ๋ฐฐ์น˜ ์ž‘์—…์„ ์–ด๋ ต๊ฒŒ ํ•œ๋‹ค. ์šฐ๋ฆฌ๋Š” ์ด์— ๋Œ€ํ•œ ํ•ด๊ฒฐ์ฑ…์„ ๋งŒ๋“ค์—ˆ๋‹ค. ์ฃผ์†Œ ์žฌ๋ฐฐ์น˜๋ฅผ ์œ„ํ•œ ์ •๋ณด๋“ค์„ ์ €์žฅํ•˜๊ธฐ์œ„ํ•ด ์˜๊ตฌ ๋ฉ”๋ชจ๋ฅผ ๋งŽ์ด ์‚ฌ์šฉํ•˜๋Š” ๊ฒƒ๋„ ๋ฌธ์ œ๊ฐ€ ๋œ๋‹ค. ๋”ฐ๋ผ์„œ ์šฐ๋ฆฌ๋Š” ์ฃผ์†Œ ์žฌ๋ฐฐ์น˜ ์ •๋ณด๋ฅผ ๋จธ์‹  ์ฝ”๋“œ ์ƒ์— ์ธ์ฝ”๋”ฉํ•˜๊ณ  ์••์ถ•ํ•˜์—ฌ ์ €์žฅํ•˜๋Š” ๋ฐฉ๋ฒ•์„ ์ œ์•ˆํ–ˆ๋‹ค. ์šฐ๋ฆฌ์˜ ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ ๊ธฐ๋ฒ•์€ ์˜ค๋ผํด์‚ฌ์˜ CDC ๊ฐ€์ƒ๋จธ์‹  ์ฐธ์กฐ๊ตฌํ˜„์ธ CVM์— ๊ตฌํ˜„ํ•˜์˜€๋‹ค. ์šฐ๋ฆฌ์˜ ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ๋Š” ๋ฒค์น˜๋งˆํฌ์˜ ์„ฑ๋Šฅ์„ ์•ฝ 12% ํ–ฅ์ƒ์‹œ์ผฐ๋‹ค. ๋˜ํ•œ ์šฐ๋ฆฌ๋Š” ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ ๊ธฐ๋ฒ•์„ ์‹ค์ œ๋กœ ํŒ๋งคํ•˜๋Š” DTVํ™˜๊ฒฝ์— ๊ตฌ์ถ•ํ•˜์—ฌ ์‹ค์ œ ๋ฐฉ์†ก๊ตญ์ด ์‚ฌ์šฉํ•˜๋Š” ์–ดํ”Œ๋ฆฌ์ผ€์ด์…˜์„ ์ˆ˜ํ–‰ํ•ด ๋ณด์•˜๋‹ค. ์šฐ๋ฆฌ์˜ ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ ๋ฐฉ์‹์€ ์‚ฌ์šฉ์ž์˜ ์‹ค์ œ ํ™˜๊ฒฝ์—์„œ 33%์˜ ์ข‹์€ ์„ฑ๋Šฅ ํ–ฅ์ƒ์„ ์–ป์—ˆ๋‹ค. ์ž๋ฐ”์Šคํฌ๋ฆฝํŠธ ๊ฐ€์ƒ๋จธ์‹ ์ธ ๊ตฌ๊ธ€์‚ฌ์˜ V8 ๊ฐ€์ƒ๋จธ์‹ ์€ ์ธํ„ฐํ”„๋ฆฌํ„ฐ ์ˆ˜ํ–‰์—†์ด ์ ์‹œ ์ปดํŒŒ์ผ๋Ÿฌ๋งŒ์„ ์‚ฌ์šฉํ•˜๊ณ  ์žˆ๋‹ค. ์šฐ๋ฆฌ๋Š” V8 ๊ฐ€์ƒ ๋จธ์‹ ์— ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ๋Š” ์ ์šฉํ•˜์˜€์ง€๋งŒ, ์‹ค์ œ ์„ฑ๋Šฅ ํ–ฅ์ƒ์„ ์–ป์–ด๋‚ด์ง€๋Š” ๋ชปํ–ˆ๋‹ค. ์ด๊ฒƒ์€ V8 ๊ฐ€์ƒ ๋จธ์‹ ์˜ ํŠน์ง•์ธ ๋‚ด๋ถ€ ๊ฐ์ฒด์˜ ์ ๊ทน์ ์ธ ์‚ฌ์šฉ์— ์˜ํ•œ ๊ฒฐ๊ณผ์ด๋‹ค. ๋‚ด๋ถ€ ๊ฐ์ฒด๋Š” ์ปดํŒŒ์ผ๋Ÿฌ๊ฐ€ ์ƒ์„ฑํ•˜์—ฌ ์ปดํŒŒ์ผ๋Ÿฌ ๊ณผ์ •์—์„œ ์‚ฌ์šฉ๋˜๋ฉฐ, ์ž๋ฐ”์Šคํฌ๋ฆฝํŠธ ํ”„๋กœ๊ทธ๋žจ์—์„œ๋„ ์ ‘๊ทผํ•˜์—ฌ ์‚ฌ์šฉํ•˜๊ฒŒ ๋œ๋‹ค. V8 ๊ฐ€์ƒ ๋จธ์‹ ์˜ ์ปดํฌ๋„ŒํŠธ๋“ค์€ ๋Œ€๋ถ€๋ถ„ ๋‚ด๋ถ€ ๊ฐ์ฒด๋กœ ์ƒ์„ฑ๋˜์–ด, ๋‹ค๋ฅธ ์ข…๋ฅ˜์˜ ๊ฐ€์ƒ ๋จธ์‹ ์— ๋น„ํ•ด์„œ ์ƒ๋‹นํžˆ ๋งŽ์€ ๋‚ด๋ถ€ ๊ฐ์ฒด๋ฅผ ์ƒ์„ฑํ•˜๊ณ  ์žˆ๋‹ค. V8์˜ ์ ์‹œ ์ปดํŒŒ์ผ๋Ÿฌ๊ฐ€ ์ƒ์„ฑํ•˜๋Š” ๋จธ์‹  ์ฝ”๋“œ์—์„œ๋Š” ์ด ๋‚ด๋ถ€ ๊ฐ์ฒด๋ฅผ ์ง์ ‘ ์ ‘๊ทผํ•˜์—ฌ ์‚ฌ์šฉํ•˜๊ฒŒ ๋˜์–ด, ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ์— ์˜ํ•ด ์–ดํ”Œ๋ฆฌ์ผ€์ด์…˜์ด ์ˆ˜ํ–‰๋  ๋•Œ๋งˆ๋‹ค ์ด ๋‚ด๋ถ€ ๊ฐ์ฒด๋Š” ํ•ญ์ƒ ํ•„์š”ํ•˜๊ธฐ ๋•Œ๋ฌธ์— ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ๋Š” ๋‚ด๋ถ€ ๊ฐ์ฒด๋ฅผ ์žฌ์ƒ์„ฑํ•ด์•ผ๋งŒ ํ•œ๋‹ค. V8 ์ ์‹œ ์ปดํŒŒ์ผ๋Ÿฌ์˜ ๋Ÿฐํƒ€์ž„ ์ปดํŒŒ์ผ๋ ˆ์ด์…˜ ์˜ค๋ฒ„ํ—ค๋“œ์˜ ๋Œ€๋ถ€๋ถ„์ด ๋‚ด๋ถ€ ๊ฐ์ฒด๋ฅผ ์ƒ์„ฑํ•˜๋Š” ์˜ค๋ฒ„ํ—ค๋“œ์ด๊ธฐ ๋•Œ๋ฌธ์—, ์šฐ๋ฆฌ์˜ ํด๋ผ์ด์–ธํŠธ ์„ ํ–‰ ์ปดํŒŒ์ผ๋Ÿฌ๋Š” ์ด ํ™˜๊ฒฝ์—์„œ ์ถฉ๋ถ„ํ•œ ์„ฑ๋Šฅ ํ–ฅ์ƒ์„ ์–ป์„ ์ˆ˜ ์—†์—ˆ๋‹ค.App-downloading systems like DTV and smart phone are popularly used. Virtual machine is mainstream for those systems. One critical problem of app-downloading systems is performance because app is executed by interpreter. A popular solution for improving performance is Just-In-Time Compiler (JITC). JITC compiles to machine code at runtime. So, JITC suffers from runtime compilation overhead. We suggested client Ahead-Of-Time Compiler(c-AOTC) which improves the performance by removing runtime compilation overhead. c-AOTC saves machine code of method generated by JITC in persistent storage and reuses it in next runs. The machine code of a method translated by JITC is cached on a persistent memory of the device, and when the method is invoked again in a later run of the program, the machine code is loaded and executed directly without any translation overhead. One major issue in c-AOTC is relocation because some of the address constants embedded in the cached machine code are not correct when the machine code is loaded and used in a different runthose addresses should be corrected before they are used. Constant pool resolution complicates the relocation problem, and we propose our solutions. The persistent memory overhead for saving the relocation information is also an issue, and we propose a technique to encode the relocation information and compress the machine code efficiently. We developed a c-AOTC on Oracles CDC VM, and evaluation results indicate that c-AOTC can improve the performance as much as an average of 12% for benchmarks. And we adopted c-AOTC approach to commercial DTV platform and test the real xlet applications of commercial broadcasting stations. c-AOTC got average 33% performance improvement on the real xlet application test. V8 JavaScript VM does not use interpreter. Apps are executed only by JITC. We adopted c-AOTC to V8 VM. But we cannot get any good performance result because of V8 VMs characteristics. V8 VM components are generated as internal objects. Internal objects are used for compiling and running of JavaScript program. The machine code of V8 VM addresses internal objects which are different for each run. Because internal objects beใ€€accessed in each run, c-AOTCใ€€must recreate those objects. Because most of compilation overhead of V8 VM is internal object creation overhead, c-AOTCใ€€does not get enough improvements.Chapter 1 Introduction 1 Chatper 2 client-AOTC Approach 4 Chatper 3 Java Virtual Machine and Our JITC 9 3.1 Overview of JVM and the Bytecode 9 3.2 Our JITC on the CVM 14 Chatper 4 Design and Implementation of c-AOTC on JVM 16 4.1 Architecutre of the c-AOTC 16 4.2 Relocation 19 4.2.1 Translated Code Which Needs Relocation 19 4.2.2 Relocation Information and Relocation Process 22 4.2.3 Relocation for Inlined Methods 24 4.3 Reducing the Size of .aotc Files 25 4.3.1 Encoding Relocation Information 25 4.3.2 Machine Code Compression 27 4.3.3 Structure of the .aotc File 27 Chatper 5 c-AOTC for DTV JVM platform 29 5.1 DTV software platform 30 5.2 c-AOTC on the DTV 32 5.2.1 Design of c-AOTC on DTV 32 5.2.2 Relocation Problem 35 5.2.3 Example of Relocation 39 5.2.3.1 Relocation Example of JVM c-AOTC 39 5.2.3.3 Relocation Example of DTV c-AOTC 41 Chatper 6 c-AOTC for JavaScript VM 44 6.1 V8 JavaScript VM 44 6.2 Issue and Solution of c-AOTC on V8 JavaScript VM 46 Chatper 7 Experimental Results 51 7.1 Experimental Environment of JVM 51 7.2 Performance Impact of c-AOTC 53 7.3 Space Overhead of c-AOTC 55 7.4 Reducing Number of c-AOTC Methods 60 7.5 c-AOTC with new hot-spot detection heuristics 63 7.5.1 Performance Impact of c-AOTC with new hot-spotdetection heuristics 63 7.5.2 Space Overhead of c-AOTC with new hot-spot detection heuristics 67 7.6 c-AOTC of DTV JVM platform 70 7.6.1 Performance result of DTV platform 70 7.6.2 Analysis of JITCed method of DTV platform 72 7.6.3 Space overhead of DTV platform 74 7.6.4 c-AOTC overhead of DTV platform 75 7.6.5 c-AOTC performance using different xlets c-AOTC file in DTV platform 76 7.7 c-AOTC of V8 JavaScript engine 79 7.7.1 Compilation overhead on V8 JavaScript VM 79 7.7.2 Performance result on V8 JavaScript VM 81 7.7.3 Comparison with c-AOTC of JavaScriptCore VM 83 Chatper 8 Related Work 86 Chatper 9 Conclusion 89 Bibliography 91 ์ดˆ๋ก 99Docto

    Differential Fuzzing the WebAssembly

    Get PDF
    WebAssembly, colloquially known as Wasm, is a specification for an intermediate representation that is suitable for the web environment, particularly in the client-side. It provides a machine abstraction and hardware-agnostic instruction sets, where a high-level programming language can target the compilation to the Wasm instead of specific hardware architecture. The JavaScript engine implements the Wasm specification and recompiles the Wasm instruction to the target machine instruction where the program is executed. Technically, Wasm is similar to a popular virtual machine bytecode, such as Java Virtual Machine (JVM) or Microsoft Intermediate Language (MSIL). There are two major implementations of Wasm, correlated with the two most popular web browsers in the market. These two are the V8 engine by Chromium project and the SpiderMonkey engine by Mozilla. Wasm does not mandate a specific implementation over its specification. Therefore, both engines may employ different mechanisms to apply the specification. These different implementations may open a research question: are both engines implementing the Wasm specification equally? In this thesis, we are going to explore the internal implementation of the JavaScript engine in regards to the Wasm specification. We experimented using a differential fuzzing technique, in which we test two JavaScript engines with a randomly generated Wasm program and compares its behavior. We executed the experiment to identify any anomalous behavior, which then we analyzed and identified the root cause of the different behavior. This thesis covers the WebAssembly specification extensively. It discusses several foundational knowledge about the specification that is currently lacking in references. This thesis also presents the instrumentation made to the JavaScript engine to perform the experiment, which can be a foundation to perform a similar experiment. Finally, this thesis analyzes the identified anomaly found in the experiment through reverse engineering techniques, such as static and dynamic analysis, combined with white-box analysis to the JavaScript engine source code. In this experiment, we discovered a different behavior of the JavaScript engine that is observable from the perspective of the Wasm program. We created a proof-of-concept to demonstrate the different behavior that can be executed in the recent web browser up to the writing of this thesis. This experiment also evaluated the implementation of both JavaScript engine on the Wasm specification to conclude that both engines implement the specification faithfully

    Simple optimizing JIT compilation of higher-order dynamic programming languages

    Get PDF
    Implรฉmenter efficacement les langages de programmation dynamiques demande beaucoup dโ€™effort de dรฉveloppement. Les compilateurs ne cessent de devenir de plus en plus complexes. Aujourdโ€™hui, ils incluent souvent une phase dโ€™interprรฉtation, plusieurs phases de compilation, plusieurs reprรฉsentations intermรฉdiaires et des analyses de code. Toutes ces techniques permettent dโ€™implรฉmenter efficacement un langage de programmation dynamique, mais leur mise en oeuvre est difficile dans un contexte oรน les ressources de dรฉveloppement sont limitรฉes. Nous proposons une nouvelle approche et de nouvelles techniques dynamiques permettant de dรฉvelopper des compilateurs performants pour les langages dynamiques avec de relativement bonnes performances et un faible effort de dรฉveloppement. Nous prรฉsentons une approche simple de compilation ร  la volรฉe qui permet dโ€™implรฉmenter un langage en une seule phase de compilation, sans transformation vers des reprรฉsentations intermรฉdiaires. Nous expliquons comment le versionnement de blocs de base, une technique de compilation existante, peut รชtre รฉtendue, sans effort de dรฉveloppement significatif, pour fonctionner interprocรฉduralement avec les langages de programmation dโ€™ordre supรฉrieur, permettant dโ€™appliquer des optimisations interprocรฉdurales sur ces langages. Nous expliquons รฉgalement comment le versionnement de blocs de base permet de supprimer certaines opรฉrations utilisรฉes pour implรฉmenter les langages dynamiques et qui impactent les performances comme les vรฉrifications de type. Nous expliquons aussi comment les compilateurs peuvent exploiter les reprรฉsentations dynamiques des valeurs par Tagging et NaN-boxing pour optimiser le code gรฉnรฉrรฉ avec peu dโ€™effort de dรฉveloppement. Nous prรฉsentons รฉgalement notre expรฉrience de dรฉveloppement dโ€™un compilateur ร  la volรฉe pour le langage de programmation Scheme, pour montrer que ces techniques permettent effectivement de construire un compilateur avec un effort moins important que les compilateurs actuels et quโ€™elles permettent de gรฉnรฉrer du code efficace, qui rivalise avec les meilleures implรฉmentations du langage Scheme.Efficiently implementing dynamic programming languages requires a significant development effort. Over the years, compilers have become more complex. Today, they typically include an interpretation phase, several compilation phases, several intermediate representations and code analyses. These techniques allow efficiently implementing these programming languages but are difficult to implement in contexts in which development resources are limited. We propose a new approach and new techniques to build optimizing just-in-time compilers for dynamic languages with relatively good performance and low development effort. We present a simple just-in-time compilation approach to implement a language with a single compilation phase, without the need to use code transformations to intermediate representations. We explain how basic block versioning, an existing compilation technique, can be extended without significant development effort, to work interprocedurally with higherorder programming languages allowing interprocedural optimizations on these languages. We also explain how basic block versioning allows removing operations used to implement dynamic languages that degrade performance, such as type checks, and how compilers can use Tagging and NaN-boxing to optimize the generated code with low development effort. We present our experience of building a JIT compiler using these techniques for the Scheme programming language to show that they indeed allow building compilers with less development effort than other implementations and that they allow generating efficient code that competes with current mature implementations of the Scheme language

    Reaching across - managing variants of one application on multiple platforms

    Get PDF
    The number of platforms to support in today's software projects are many and there are a wide range of differences to consider. There are tons of programming languages on the market and each platform, both mobile and desktop, have different preferences on how to develop applications. This do often result in multiple applications, similar to the end user but different to the developers. The same functionality has to be developed and maintained in multiple versions of the application in different ways. To solve these issues there is a need to think of the applications and platform in a new way. They have to be unified and commonalities has to be found or made. New application structures and tools are also needed to keep the platforms in sync. When developing those concepts each platformโ€™s flexibility must be protected. Each platform has itโ€™s own advantages and features like a GPS and camera and they have to be available to build a competitive product. This report concludes that web technology such as HTML5, JavaScript and CSS is a promising way to introduce common parts in the application. This helps to manage the platforms in one way and reduces the differences. To retain the platform specifics, language bridges are used to directly communicate with the native platform from the web parts. This enables the full strength of each platform and makes the solution a fully featured competitor to native applications
    • โ€ฆ
    corecore