đề xuất thiết kế: llvm nhiều ngữ cảnh thời gian chạy

Question

Ứng dụng của tôi cần chạy nhiều ngữ cảnh riêng biệt trong cùng một quy trình (đơn luồng). Tất cả đều chia sẻ một đơn LLVMContext.

Quy trình sẽ chạy nhiều ngữ cảnh (theo ý nghĩa luồng); nghĩa là, mỗi hàm chạy một hàm trong đối tượng tiếp tục dựa trên boost::context (vẫn còn trên vòm, lib đã được phê duyệt trước), điều đó có nghĩa là mỗi ngữ cảnh có thể sinh lợi nhưng về cơ bản chúng chạy trong cùng một quy trình một luồng. Mỗi người nên chạy về cơ bản độc lập với nhau, và quan trọng hơn, một lỗi biên dịch trong mỗi một không nên ảnh hưởng đến việc thực hiện của những người khác.

Mỗi ngữ cảnh này, sẽ gọi mã động kéo dài nhiều đơn vị dịch (TU). một số đơn vị dịch thuật có thể được chia sẻ trong nhiều ngữ cảnh này. lỗi biên dịch trong một đơn vị dịch mới hoặc đã sửa đổi sẽ không ảnh hưởng đến các ngữ cảnh khác.

Làm rõ Chỉnh sửa: Ví dụ: T.U. A có thể được chia sẻ giữa hai bối cảnh, ngữ cảnh X và Y. chỉ vì có một bức tranh đầy đủ, cho phép nói rằng X cũng sẽ chạy mã từ các đơn vị dịch khác, Ie B và D, trong khi Y cũng sẽ có C. Tại một số điểm, X quyết định sửa đổi thành A, vì vậy nó tạo ra một TU A.1 mới, là bản sao của A và áp dụng sửa đổi ở đó, vì vậy chúng sẽ không ảnh hưởng đến bối cảnh Y. Hy vọng ví dụ này làm rõ yêu cầu.

xung ban đầu của tôi là kết hợp một llvm::Module cho từng bối cảnh, nhưng vì không xác định của nó trong LLVM gì xảy ra với một mô-đun trong một trạng thái trung gian biên soạn, tôi quyết định thêm một llvm::Module cho mỗi đơn vị dịch thuật (xem this question for the reason), cộng với chính sách copy-on-write mà tôi đã giải thích trước đây khi các sửa đổi của một đơn vị dịch diễn ra cục bộ trong một ngữ cảnh, để tránh một sửa đổi ảnh hưởng đến các ngữ cảnh khác.

Câu hỏi hai lần chính tôi đã có là:

• Làm thế nào để liên kết với nhau các module khác nhau trong một bối cảnh để gọi chúng như một thư viện thống nhất? Tôi đang sử dụng api C++. Tôi đặc biệt cảnh giác với this nasty, old bug ảnh hưởng đến chức năng này. Liệu lỗi này có ảnh hưởng đến tôi không nếu tôi chuyển quyền sở hữu tất cả các mô-đun cho JIT bằng ExecutionEngine::addModule()?

• Các bước được yêu cầu khi sửa đổi trên một đơn vị dịch buộc phải cập nhật một trong các mô-đun là gì? sao tôi cần phải xóa/xóa đối tượng mô-đun cũ và tạo một đối tượng mới? Có chính sách tái chế nào mà tôi chưa đọc?

Một câu hỏi thứ tôi có về vấn đề này là:

• bao nhiêu ExecutionEngine nào tôi cần? một cho toàn bộ ứng dụng? một cho mỗi ngữ cảnh? mỗi mô-đun một?

Hy vọng phạm vi của câu hỏi không quá áp đảo.

Answer 1

Tôi nghĩ bạn cần một khung khái niệm để "treo" ý tưởng của mình. Suy nghĩ về các bit thực hiện khác nhau như các lệnh (có lẽ thậm chí thực hiện bằng cách sử dụng mẫu lệnh) sẽ cung cấp cho bạn một tập hợp các điểm tương tác rõ ràng hơn. Điều đó đang được nói; bạn sẽ cần một ngữ cảnh cho mỗi lần thực thi rời rạc mà bạn muốn quay lại. Nhiều hơn hai sẽ yêu cầu bạn tạo sổ sách phù hợp. Tôi tin rằng hai là xử lý cơ bản miễn phí trong tăng.
Giao tiếp giữa các bit thực thi tương tự như bạn. Tạo một trạng thái (lưu trữ) được chia sẻ qua các bối cảnh thực thi là một giải pháp có trong tâm trí. Bạn cũng có thể đã có trạng thái phù hợp được xây dựng trong thời gian chạy của bạn, sau đó không có lớp bổ sung sẽ được yêu cầu. Khi bạn chỉ ra các hình cầu không phải là bạn của bạn trong những tương tác này. Phân giải phiên bản và tên cũng là một vấn đề. Việc giữ các bit thực thi riêng biệt sẽ đi một chặng đường dài để giải quyết vấn đề này. Một khi bạn giải quyết vấn đề phối hợp, đây là vấn đề theo dõi những bit bạn đã tạo ra. Điều này cũng có nghĩa là không cần tái chế, chỉ cần tạo mới mỗi lần và không có tải lại. Bạn cũng sẽ phải quản lý phần cuối của cuộc sống của những bit này một khi họ đã hoàn thành việc thực thi. Tôi đang đề xuất một ExecutionEngine mỗi bit thi hành. Để không làm điều này có nghĩa là một công việc lớn hơn nhiều cố gắng để "bảo vệ" mã làm việc từ những tác động của mã đó là sai. Tôi tin rằng nó có thể làm điều này với một động cơ duy nhất, nhưng nó sẽ là nguy hiểm hơn đáng kể.