Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006217OCamlOCaml backend (code generation)public2013-10-30 15:082014-09-15 23:26
Reporterppedrot 
Assigned To 
PrioritynormalSeveritytweakReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version4.01.0 
Target Versionafter-4.02.1Fixed in Version 
Summary0006217: Compilation of record functional modification is costly
DescriptionCurrently, compilation of the { r with ... } expression seems to have a length threshold that triggers a change in the way it is compiled. For instance,

type t = {
  t1 : int option;
  t2 : int option;
  t3 : int option;
  t4 : int option;
  t5 : int option;
}

let set1 x t = {
  t with t1 = Some x;
}

produces a direct allocation on the minor heap, together with a bunch of assembly moves that copy the record fieldwise. Problem is, adding a [t6 : int option] field changes this to an [Obj.dup] followed by a [caml_modify].

I don't know if this has been decided with respect to some benchmarks, but [caml_modify] is really costly, and for the record (no pun intended), this overhead was indeed observable in Coq. Maybe this threshold should be incremented?
Tagsjunior_job
Attached Files

- Relationships

-  Notes
(0012139)
doligez (administrator)
2014-09-15 23:17

There is another problem with this: if the record is immutable it's possible that, in the near future, the call to [caml_modify] will break the GC's invariants.

- Issue History
Date Modified Username Field Change
2013-10-30 15:08 ppedrot New Issue
2014-06-19 17:42 gasche Tag Attached: junior_job
2014-07-16 13:49 doligez Status new => acknowledged
2014-07-30 21:01 doligez Target Version => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-15 23:17 doligez Note Added: 0012139
2014-09-15 23:17 doligez Target Version undecided => after-4.02.1


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker