12

我想知道为什么我们从编译打印“Hello, World!”的 .c 文件中得到的 .o 文件。是否比也打印“Hello, World!”的 Java .class 文件大？

4

9 回答 9

15

Java 使用字节码是平台独立和“预编译”的，但字节码是由解释器使用的，并且足够紧凑，所以它与您在编译的 C 程序中看到的机器码不同。看一下Java编译的全过程：

Java program  
-> Bytecode   
  -> High-level Intermediate Representation (HIR)   
    -> Middle-level Intermediate Representation (MIR)   
      -> Low-level Intermediate Representation (LIR)  
        -> Register allocation
          -> EMIT (Machine Code)

这是 Java 程序到机器代码转换的链。如您所见，字节码与机器码相去甚远。我在网上找不到好东西给你展示这条路的真实程序（一个例子），我找到的都是这个演示文稿，在这里你可以看到每个步骤如何更改代码演示文稿。我希望它能回答你编译的 c 程序和 Java 字节码是如何以及为什么不同的。

更新： “字节码”之后的所有步骤都由 JVM 在运行时完成，具体取决于其编译该代码的决定（这是另一个故事...... JVM 正在字节码解释和编译为本机平台相关代码之间取得平衡）

终于找到了一个很好的例子，取自Java HotSpot™ 客户端编译器的线性扫描寄存器分配（顺便说一句，阅读很好，可以了解 JVM 内部发生了什么）。假设我们有 java 程序：

public static void fibonacci() {
  int lo = 0;
  int hi = 1;
  while (hi < 10000) {
    hi = hi + lo;
    lo = hi - lo;
    print(lo);
  }
}

那么它的字节码是：

0:  iconst_0
1:  istore_0 // lo = 0
2:  iconst_1
3:  istore_1 // hi = 1
4:  iload_1
5:  sipush 10000
8:  if_icmpge 26 // while (hi < 10000)
11: iload_1
12: iload_0
13: iadd
14: istore_1 // hi = hi + lo
15: iload_1
16: iload_0
17: isub
18: istore_0 // lo = hi - lo
19: iload_0
20: invokestatic #12 // print(lo)
23: goto 4 // end of while-loop
26: return

每个命令占用 1 个字节（JVM 支持 256 个命令，但实际上少于该数量）+ 参数。总共需要 27 个字节。我省略了所有阶段，这里准备执行机器代码：

00000000: mov dword ptr [esp-3000h], eax
00000007: push ebp
00000008: mov ebp, esp
0000000a: sub esp, 18h
0000000d: mov esi, 1h
00000012: mov edi, 0h
00000017: nop
00000018: cmp esi, 2710h
0000001e: jge 00000049
00000024: add esi, edi
00000026: mov ebx, esi
00000028: sub ebx, edi
0000002a: mov dword ptr [esp], ebx
0000002d: mov dword ptr [ebp-8h], ebx
00000030: mov dword ptr [ebp-4h], esi
00000033: call 00a50d40
00000038: mov esi, dword ptr [ebp-4h]
0000003b: mov edi, dword ptr [ebp-8h]
0000003e: test dword ptr [370000h], eax
00000044: jmp 00000018
00000049: mov esp, ebp
0000004b: pop ebp
0000004c: test dword ptr [370000h], eax
00000052: ret

结果需要 83 个（十六进制的 52 个 + 1 个字节）字节。

PS。我没有考虑链接（其他人提到过），以及compiledc和字节码文件头（可能它们也不同；我不知道c如何，但在字节码文件中所有字符串都被移动到特殊的标头池，并且在程序中在标头等中使用了它的“位置”。）

UPDATE2：可能值得一提的是，java 使用堆栈（istore/iload 命令），尽管基于 x86 的机器代码和大多数其他平台使用寄存器。如您所见，机器代码“充满”了寄存器，与更简单的基于堆栈的字节码相比，它为编译的程序提供了额外的大小。

于 2011-01-29T17:54:05.173 回答
7

在这种情况下，大小差异的主要原因是文件格式的差异。对于如此小的程序格式，ELF( .o) 文件在空间方面引入了严重的开销。

例如，我.o的“Hello, world”程序的示例文件需要864 字节。它包括（用readelf命令探索）：

  • 52字节的文件头
  • 440 字节的节头（40 字节 x 11 节）
  • 81字节的段名
  • 160字节的符号表
  • 43字节的代码
  • 14 字节数据( Hello, world\n\0)
  • ETC

.class类似程序的文件只占用415 字节，尽管它包含更多符号名称并且这些名称很长。它包括（使用Java Class Viewer探索）：

  • 289 字节的常量池（包括常量、符号名称等）
  • 94字节的方法表（代码）
  • 8字节属性表（源文件名参考）
  • 24 字节的固定大小的标头

也可以看看：

于 2011-01-29T18:08:35.777 回答
4

C 程序，即使它们被编译为在您的处理器上运行的本机机器代码（当然是通过操作系统调度），也往往需要为操作系统进行大量设置和拆卸，加载动态链接C库等库。

另一方面，Java 编译为虚拟平台（基本上是计算机中的模拟计算机）的字节码，该平台是与 Java 本身一起专门设计的，所以很多这种开销（如果它甚至是必要的，因为两者都是代码和 VM 接口定义良好）可以移动到 VM 本身中，从而使程序代码精简。

但是，它因编译器而异，并且有几个选项可以减少它或以不同的方式构建代码，这将产生不同的效果。

说了这么多，其实没那么重要。

于 2011-01-29T17:24:41.553 回答
1

简而言之：Java程序被编译成Java字节码，需要一个单独的解释器（Java虚拟机）来执行。

不能 100% 保证 c 编译器生成的 .o 文件小于 Java 编译器生成的 .class 文件。这一切都取决于编译器的实现。

于 2011-01-29T17:27:05.717 回答
1

类文件是 Java 字节码。

它很可能更小，因为 C/C++ 库和操作系统库链接到 C++ 编译器生成的最终生成可执行二进制文件的目标代码。

简而言之，这就像将 Java 字节码与 C 编译器生成的目标代码进行比较，然后再将其链接以创建二进制文件。不同之处在于 JVM 解释 Java 字节码以正确执行程序应执行的操作，而 C 需要来自操作系统的信息，因为操作系统充当解释器。

同样在 C 中，您从外部库引用的每个符号（函数等）至少在其中一个目标文件中被导入一次。如果您在多个目标文件中使用它，它仍然只导入一次。这种“导入”有两种方式发生。使用静态链接，函数的实际代码被复制到可执行文件中。这会增加文件大小，但具有不需要外部库（.dll/.so 文件）的优点。使用动态链接不会发生这种情况，但因此您的程序需要额外的库才能运行。

在 Java 中，可以说，一切都是动态“链接”的。

于 2011-01-29T17:23:55.713 回答
1

.o文件大小和文件大小不同的主要原因之一.class是 Java 字节码比机器指令高级一点。当然，不是非常高级——它仍然是相当低级的东西——但这会有所不同，因为它有效地压缩了整个程序。（C 和 Java 代码都可以在其中包含启动代码。）

另一个区别是 Java 类文件通常代表相对较小的功能块。虽然可以将 C 目标文件映射到更小的部分，但将更多（相关）功能放在单个文件中通常更常见。范围规则的差异也可以强调这一点（C 实际上没有任何与模块级范围相对应的东西，但它确实具有文件级范围；Java 的包范围适用于多个类文件）。如果你比较整个程序的大小，你会得到一个更好的指标。

就“链接”大小而言，Java 可执行 JAR 文件往往更小（对于给定的功能级别），因为它们是压缩交付的。以压缩形式交付 C 程序相对较少。（标准库的大小也存在差异，但它们也可能是一种清洗，因为 C 程序可以依赖 libc 以外的库，而 Java 程序可以访问一个巨大的标准库。挑选谁有优势很尴尬。）

然后，还有调试信息的问题。特别是，如果你编译一个带有调试功能的 C 程序，那么你会得到很多关于包含在标准库中的类型的信息，只是因为过滤掉它有点太尴尬了。Java 代码将仅具有有关实际编译代码的调试信息，因为它可以依靠目标文件中可用的相关信息。这会改变代码的实际大小吗？不会。但它会对文件大小产生很大影响。

总的来说，我猜很难比较 C 和 Java 程序的大小。或者更确切地说，您可以比较它们并轻松学到什么有用的东西。

于 2011-01-29T17:53:40.493 回答
1

ELF 格式文件的大部分（对于简单函数来说高达 90%）.o都是垃圾文件。对于.o包含单个空函数体的文件，您可以预期大小细分如下：

  • 1% 代码
  • 9% 符号和重定位表（链接必不可少）
  • 90% 的头文件开销、编译器和/或汇编器存储的无用版本/供应商注释等。

如果您想查看编译后的 C 代码的实际大小，请使用该size命令。

于 2011-01-29T19:55:05.097 回答
0

Java 被编译成与机器无关的语言。这意味着在编译之后，它会在运行时由 Java 虚拟机 (JVM) 进行翻译。C被编译为机器指令，因此是程序在目标机器上运行的所有二进制文件。

因为 Java 被编译为与机器无关的语言，特定机器的特定细节由 JVM 处理。（即 C 具有特定于机器的开销）

反正我就是这么想的:-)

于 2011-01-29T17:24:40.427 回答
-1

几个潜在的原因：

  • Java 类文件根本不包含初始化代码。它只有一个类和一个功能 - 确实非常小。相比之下，C 程序有一定程度的静态链接初始化代码，可能还有 DLL thunk。
  • C 程序也可能有与页边界对齐的部分——这将像这样为程序大小增加至少 4kb，以确保代码段从页边界开始。
于 2011-01-29T17:33:37.963 回答