0

When the JVM was originally drawn up, the designers had the CONSTANT_Long_info and CONSTANT_Double_info structures in the constant pool take up 2 entries (supposedly because that way you could index the constant pool by 4-byte alignment or something along those lines).

However, according to the JVM 10 specification, that has not been changed.

If changing it would require changes to a lot of code it would make sense since the JVM is supposed to be able to run code built for older JVMs, but it seems to me that it would require very few changes with a conditional to determine if you're dealing with a class from an earlier version — the only times it's relevant are if you're initializing the constant pool or if you're iterating over it, which doesn't happen very often and is riddled with conditionals anyways.

Besides, far larger breaking changes such as Java 9 modules have been introduced in the past. So, why is it still like that today? Is there an architectural reason, or is it just not worth anyone's time so far?

Holger
  • 285,553
  • 42
  • 434
  • 765
GoogleBen
  • 28
  • 4
  • 1
    Let's ask another way: *why change this if it works well for both old and new JVM versions?* – apangin Sep 14 '18 at 10:45
  • Think of 32-bit JVMs (e.g. on ARM platform). It's natural for them to have 32-bit contant pool entries, that is, 64-bit constants will occupy two slots. – apangin Sep 14 '18 at 10:55
  • 1
    @apangin well, [the specification](https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-4.html#jvms-4.4.5) itself says “*In retrospect, making 8-byte constants take two constant pool entries was a poor choice*” and I’d agree, as even for 32 bit environments, it’s trivial to convert to an IR using 32 bit runtime entries in a single pass and there’s a pre-processing anyway. There’s no need to reserve such entries in the stored class files. But you’re right in “*why change this if it works*”, especially if we do not gain anything from the change. – Holger Sep 14 '18 at 11:25

1 Answers1

2

Like with most changes from Java 1.1 to Java 11, the introduction of modules did not change so much when it comes to the bytecode format. It may be radical when it comes to application logic or Reflection, by not for byte code processing tools, which only needed slight extensions.

Changing the logic of CONSTANT_Long_info and CONSTANT_Double_info would only make sense if you go for the bigger picture, e.g. also change the fact that long and double take two local variables and two operand stack entries. Then, you will have to touch quiet a lot code places.

But regardless of how little or big the changes are, the important question is, what do you gain in exchange? A better feeling does not count. The main reason to change it, would be to simplify the rules and hence, the bytecode processing tools. But since these tools would need conditionals to enable the still present handling of older class files, this advantage would not materialize. In fact, the tools would become more complex with such a change.

It would be different when you develop an entirely new format which requires new tools anyway, e.g. it would have been an option for the JMOD format, but exactly the need to develop the new toolchain is the reason why it didn’t happen and the current JMOD is just a zip file like the old jar files.

A counter example is the StackMapTable attribute which had no backward-compatibility constraints when being developed and therefore, does not count long and double entries twice. It’s the duty of the processing tool to convert these stackmap entries to the stack frame entries which do use two for long and double values (unless we’re talking about an environment which does the conversion the other way round).

Holger
  • 285,553
  • 42
  • 434
  • 765