作為一種支持面向對象抽象和軟件組件可擴展組合的高級編程語言,Java是開發用戶界面和應用程序軟件的理想選擇。然而,Java軟件如何最有效地解決嵌入式軟件典型的低級問題并且通常用C語言編程,這一點還不太明顯。然而,新的硬實時Java技術針對的是低級嵌入式實時開發的特殊需求?并擊敗了混合C和Java混合語言方法。
嵌入式系統與構建它們的人以及它們執行的底層執行引擎一樣多。同樣,在為低級實時計算(ìrubber 與道路相遇)選擇Java 運行時環境時,一刀切的解決方案既不可行也不實用。
在聲稱支持實時垃圾回收的現有虛擬機中,每個虛擬機提供的功能略有不同,表示對軟實時截止時間的不同程度的遵守,其中內存限制和虛擬機占用無關。較少數量的虛擬機可以處理較低級別的要求,其中硬實時截止時間、執行速度和內存占用更為重要。通常,這些虛擬機與管理底層硬件服務的底層操作系統或 RTOS 共存。但是,事實是:有時這還不夠好。有時,Java軟件需要超越硬件抽象層,直接與硬件設備通信。
在Java越來越被認為是首選語言的世界中,擁有自上而下的完整應用程序覆蓋的虛擬機技術可能是一個顯著的優勢。許多嵌入式 Java 應用程序都是使用兩種語言方法構建的。Java 用于應用程序的更大、更復雜和更動態的部分,而 C 用于較低級別的功能,例如設備驅動程序或需要更快吞吐量的應用程序部分。
這種選擇的影響會導致通過將Java和C應用程序鏈接在一起的Java本機接口(JNI)進行尷尬和不可預測的轉換。人們這樣做的原因很明顯:傳統的虛擬機太大、太慢、太不可預測,無法處理低級執行。因此,新推出的硬實時Java技術現在可以使用Java語言而不是C來解決低級實時問題。與JNI技術相比,這種硬實時Java技術還為將傳統的高級Java代碼連接到低級C代碼提供了卓越的性能和健壯性。硬實時 Java 現在可以取代 C 代碼來實現直接與硬件通信的設備驅動程序。這允許僅Java的連續統一體,從成熟的Java的1到10秒響應時間,一直到硬實時Java的10微秒響應時間,這是解決硬件線速度所必需的。
用 Java 替換 C
混合語言方法的弱點是幾個方面的。首先,每當應用軟件跨越Java和C執行之間的邊界時,JNI協議都會提取高收費。此協議開銷可能是可執行代碼成本的兩倍以上,它破壞了將 C 語言用于應用程序的某些性能關鍵部分的許多性能優勢。其次,更重要的是,Java 安全模型會因在
應用程序中引入 C 代碼而受到損害。在過去 10 年構建的大量嵌入式 Java 應用程序中,代表超過 100 萬行嵌入式 Java 代碼,Aonix 支持工程師發現,C 和 Java 代碼之間的 JNI 接口代表了最常見的故障點。
使此問題更加復雜的是,這些錯誤是最難調試的錯誤之一。這是因為無意中破壞了 JNI 協議的 C 程序員會使隨附的 Java 虛擬機處于不穩定狀態。該錯誤可能表現為 Java 應用程序代碼或 Java 虛擬機本身的實現中的錯誤。虛擬機供應商、Java 應用程序開發人員和 C 開發人員之間的相互指責結果。
Java 規范請求 (JSR) 302 正在開發硬實時安全關鍵型 Java 編程的標準方法。除了支持核電站關閉和商用飛機控制等應用的嚴格安全認證要求外,安全關鍵型Java標準還代表了適用于Java語言開發各種低級代碼的基礎。這個不斷發展的標準的原型實現已經證明,在內存占用(超過 100 倍)、吞吐量(高達 3 倍)和確定性(數千倍)方面顯著節省成本。這種低級 Java 代碼能夠展示優化 C 語言 10% 以內的性能
特征。它能夠通過支持一級中斷處理程序的Java 實現和設備寄存器輸入和輸出操作來直接控制設備硬件。
對于那些必須構建從動態高級復雜性到靜態低級簡單性的分層軟件體系結構的人來說,已經設計了一種機制,允許非常高效和健壯地集成低級
硬實時Java組件與高級傳統Java組件。從長期工程角度來看,在整個應用程序中消除 C 代碼可以產生更好的控制、更高的可預測性、更低的軟件維護成本和更長的軟件壽命。
性能結果
Aonix 演示具有計算密集型分形程序,其中分形渲染以 C 或硬實時 Java 代碼實現。在這兩種情況下,圖形顯示都是用Java編程的,帶有SWT圖形接口。演示揭示的全 Java 性能提升是高級和低級 Java 代碼之間更清晰集成的好處。全 Java 解決方案清楚地顯示了在高級 Java 代碼和低級 C 代碼之間進行集成所需的 Java 本機接口帶來的低效率。
該演示是在嵌入式 Linux 環境中運行的,對于此特定演示,不需要解決裸硬件問題。事實上,傳統的Java和硬實時Java技術將在大多數嵌入式操作系統和商業RTOS環境中運行。硬實時Java技術非常簡單,也可以安裝在裸硬件上運行,而無需底層操作系統。
除了從應用程序中消除 C 語言提高了可靠性、可維護性和開發人員生產力之外,此演示還表明,全 Java 解決方案的運行速度比等效的 Java-C混合程序高出 2 比 1。確切的加速比取決于縮放系數和窗口大小。通過一個特定的測量,全Java程序的運行速度比混合程序快2.33倍。
全 Java 解決方案簡化了開發、集成和維護
沒有放之四海而皆準的JVM,但是現在硬實時Java提供了一種單一來源的Java補救措施,可以覆蓋嵌入式實時應用程序的所有級別,從高級應用程序復雜性一直到最低級別的硬件。
審核編輯:郭婷
-
嵌入式
+關注
關注
5147文章
19613瀏覽量
316457 -
JAVA
+關注
關注
20文章
2988瀏覽量
108668
發布評論請先 登錄
明遠智睿SSD2351開發板:嵌入式開發領域的新型新星
嵌入式開發入門指南:從零開始學習嵌入式
嵌入式開發:高門檻的系統性工程與 996 的行業困局

Python在嵌入式系統中的應用場景
BlackBerry QNX推出通用嵌入式開發平臺
AI來襲!嵌入式開發者該如何應對轉型?

代碼+案例+生態:武漢芯源半導體CW32嵌入式開發實戰正式出版

代碼+案例+生態:武漢芯源半導體CW32嵌入式開發實戰正式出版
如何成為嵌入式開發工程師?
哪些專業適合學習嵌入式開發?
嵌入式開發必備-RK3562演示Linux常用系統查詢命令(上)觸覺智能出品

如何使用 RISC-V 進行嵌入式開發
嵌入式開發常見問題排查

評論