|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000522||mercury||Bug||public||2020-10-08 21:55||2020-10-16 07:15|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000522: Compiler not building in Java grade with rotd-2020-09-29 onwards|
|Description||The 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
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
|Tags||No tags attached.|
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?
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.
|Fix committed 2020 oct 13.|
|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|