Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000522mercuryBugpublic2020-10-08 21:552020-10-16 07:15
Reporterjuliensf 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
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.
Relationships
Attached Files

Notes
(0001109)
zs   
2020-10-08 22:04   
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   
2020-10-08 22:28   
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   
2020-10-16 07:15   
Fix committed 2020 oct 13.

Issue History
Date ModifiedUsernameFieldChange
2020-10-08 21:55juliensfNew Issue
2020-10-08 22:04zsNote Added: 0001109
2020-10-08 22:28juliensfNote Added: 0001110
2020-10-16 07:15zsAssigned To => zs
2020-10-16 07:15zsStatusnew => resolved
2020-10-16 07:15zsResolutionopen => fixed
2020-10-16 07:15zsNote Added: 0001121