This service is available only in Japanese-language.

kirkstoneのmeta-javaについて

作成者:ntaka8765 作成日:2024/7/3 (水) 13:45

Ti社製AM3358において、dunfellからkirkstoneに上げた後
meta-javaの動きが遅くなりまともに使えないものとなってしまい、
対処方法に関して相談させてください。

具体的には
java -help　と打った時の応答時間がdunfell時に7[s]程度に対して2分程度
かかるようになっています。

/usr/lib/jvm/openjre-8/lib/aarch32/client/libjvm.so

をdunfellでビルドしたmeta-javaの環境から持ってきたものと入れ替えを実施したところ改善し、
25[s]程度で応答が返るようになりました。

kirkstone版のmeta-javaでビルドしたものそのままを使用するのが正しい方法かと思いますが
このままではdunfell版のと差し替えしないと十分なパフォーマンスが得られません。

もし良い方法があれば教示いただきたくお願いします。

みつきん

2024/7/6 (土) 17:40

本件回答します。

下記の情報しかないため、推測となります。

AM3358 + meta-java
* kirkstone
* dunfell
* java -helpの実行時間

再現環境として当方では下記の環境を使用しました

* ボード = BeagleBone Black(AM3358のリファレンスとして)
* MACHINE = "beaglebone-yocto"
* meta-java追加
* kirkstone / dunfell で、それぞれopenjre-8-test-image作成
* ターゲット上で time java -help実行

それぞれの実行結果は以下のようになっています。

Kirkstone --------------
Poky (Yocto Project Reference Distro) 4.0.19 beaglebone-yocto /dev/ttyS0

beaglebone-yocto login: root
root@beaglebone-yocto:~# time java -help
(省略)
real 0m1.605s
user 0m0.747s
sys 0m0.249s
root@beaglebone-yocto:~#
------------------------

Dunfell ----------------
Poky (Yocto Project Reference Distro) 3.1.33 beaglebone-yocto /dev/ttyS0

beaglebone-yocto login: root
root@beaglebone-yocto:~# time java -help
(省略)
real 0m2.684s
user 0m0.759s
sys 0m0.266s
root@beaglebone-yocto:~#

------------------------

このように実行結果にほとんど差がないため ntaka8765 様の環境固有の問題かと思われます。
こちらとしてはこれ以上の調査は難しいと思われます。
以下の点確認してみてください。

* buildディレクトリを使いまわしていないか？
* kirkstone / dunfell間で sstate-cacheを共有していないか？
* カスタムボードなどであれば、環境固有のカスタマイズがないか？

一度クリーンな環境でリファレンスボードを使用して切り分けをすると
調査がしやすいかと存じますので、ご検討ください。

以下、当方の詳細な確認手順となります。

```
$ mkdir kirkstone(or dunfell) && cd kirkstone(or dunfell)
$ git clone git://git.yoctoproject.org/poky.git -b kirkstone(or dunfell)
$ source poky/oe-init-buile-env
$ vim conf/local.conf
(MACHINE = "beaglebone-yocto"を設定)
$ bitbake-layers layerindex-fetch meta-java
$ bitbake openjre-8-test-image
```

生成されたイメージでSDカードを作成し、BeagleBone Blackで下記を実行

```
# time java -help
```

以上となります。

ntaka8765

2024/7/10 (水) 10:36

回答ありがとうございます。
こちらの環境に問題がある可能性が高いとの理解をしました。

buildディレクトリはクリアできていますので、sstateのクリアの前後での比較をまず進めていく予定です。

もう一点確認させてください。

Yoctoビルド中に以下のワーニングが出ましたが、
devtoolによる何等かの対応が必要かどうかわかりますでしょうか。

meta-javaのブランチ情報は以下となります。
branch:kirkstone
commit：2926885ebb4c3780789918e0d2ce5ee42cf115a5

以下ワーニングメッセージ
The context lines in the patches can be updated with devtool:

devtool modify openjre-8
devtool finish --force-patch-refresh openjre-8 <layer_path>

Don't forget to review changes done by devtool!

WARNING: openjre-8-272-r0 do_patch: QA Issue: Patch log indicates that
patches do not apply cleanly. [patch-fuzz]

以上、ご確認お願いします。

みつきん

2024/8/2 (金) 14:20

本件、回答します。お時間をいただきすみません。

まず、fuzzにつきまして下記をwikipediaのpatchから引用します。

https://ja.wikipedia.org/wiki/Patch

> また修正箇所近辺の内容が違っている場合も対処可能である（fuzz）。ただし、独自の修正を加えられたソースにパッチを適用して正しく動作するかは保証されない。

つまり、パッチを適用する対象とパッチファイルが作成された時点のコードの内容が異なっているが、
機械的にパッチを適用することができた。という状態になっています。

これでコンパイルが成功し、意図通りの挙動になっている場合は特に対応は必要ありません。
ただし、patchコマンドの立場としてfuzzでパッチが適用されたコードの動作は保証されないため
自分できちんと確認する必要があります。

提示いただいたログの内容ではどのpatchがfuzzになっているかわかりませんので
当方で、この対応が必要かどうかは判断いたしかねます。

よろしくお願いします。