Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005009OCaml~DO NOT USE (was: OCaml general)public2010-03-29 23:122015-12-11 19:25
Assigned Tofrisch 
PlatformOSOS Version
Product Version3.11.2 
Target Version4.02.0+devFixed in Version4.02.0+dev 
Summary0005009: Extending exception tag blocks
DescriptionWe have recently run into a problem (efficient S-expression converters for exceptions) that could be easily solved with a presumably small change to the OCaml-runtime.

Currently exception values have a pointer as first field that points to a block whose address uniquely identifies the kind of exception (lets call it "exception tag block"), e.g. as required for local modules, functor instantiations, etc. This block only stores a pointer to the string representing the exception constructor.

This makes it seemingly impossible to look up a converter for an exception in less than linear time, which may not be good enough for applications that e.g. instantiate a large number of functors or create many local modules in a loop.

The reason is that the address of the exception tag block is the only thing unique about it and it can change due to garbage collection, which prohibits the use of lookup tables/maps.

By extending the exception tag block, which currently only holds the pointer to the constructor string, by another word (or maybe two on 32bit architectures), it would be possible to store another, non-volatile piece of information that could uniquely identify the kind of exception. This would allow us to create the lookup tables required for O(log(N)) lookups.

A global 64bit counter in the OCaml runtime, for example, could then be used to generate unique ids at acceptably low cost. Exception values would not suffer any penalty. Only new instantiations of exceptions (as with functors, local modules, possibly first-class modules in the future, etc.) would see a tiny amount of extra cost.

Do you think this extension to exception tag blocks could make it into the OCaml runtime?
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
frisch (developer)
2013-10-23 16:51

Commit 14239 on the raise_variants branch modifies the representation of exception slots, reusing the existing unique id machinery from object values.

Commit 14240 introduces a function Printexc.exn_slot_id (exn -> int) returning the unique id of the constructor used to create an exception value.
frisch (developer)
2013-11-13 15:05

raise_variants branch has been merged into trunk (rev 14289).

- Issue History
Date Modified Username Field Change
2010-03-29 23:12 mottl New Issue
2011-06-01 17:16 doligez Status new => acknowledged
2013-10-23 16:51 frisch Note Added: 0010523
2013-10-23 16:51 frisch Assigned To => frisch
2013-10-23 16:51 frisch Target Version => 4.02.0+dev
2013-11-13 15:05 frisch Status acknowledged => resolved
2013-11-13 15:05 frisch Fixed in Version => 4.02.0+dev
2013-11-13 15:05 frisch Resolution open => fixed
2013-11-13 15:05 frisch Note Added: 0010632
2015-12-11 19:25 xleroy Status resolved => closed
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker