2020-10-24 11:20 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000522mercuryBugpublic2020-10-16 07:15
Reporterjuliensf 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000522: Compiler not building in Java grade with rotd-2020-09-29 onwards
DescriptionThe Java code we generate for update_opt_tuple/7 in compiler/optimization_options.m exceeds the 64k limit on method byte code size in Java.

Making Java class files
Mercury/javas/jmercury/libs__optimization_options.java:13287: error: code too large
  update_opt_tuple_7_p_0(
  ^
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0001109

zs (developer)

The obvious fix is to make each arm of the switch
its own predicate. I can do that, if you like.

BTW, why the hell is such a limit still in effect
in 2020, especially without an override flag?
Are they concerned about porting programs to PDP-11s?

~0001110

juliensf (administrator)

Thanks, I suspect that's probably the best short term fix for this. (A better fix might be to get the
MLDS->Java code generator to do such splitting on switches past a certain size threshold, but
that may too much work for one instance of the problem.)

IIRC, that limit (and a few others) are pretty deeply baked into the design of the JVM and changing
them while preserving backwards compatibility would be non trivial.

~0001121

zs (developer)

Fix committed 2020 oct 13.
+Notes

-Issue History
Date Modified Username Field Change
2020-10-08 21:55 juliensf New Issue
2020-10-08 22:04 zs Note Added: 0001109
2020-10-08 22:28 juliensf Note Added: 0001110
2020-10-16 07:15 zs Assigned To => zs
2020-10-16 07:15 zs Status new => resolved
2020-10-16 07:15 zs Resolution open => fixed
2020-10-16 07:15 zs Note Added: 0001121
+Issue History