On Fri, Aug 19, 2016 at 11:51 PM, Erik Schnetter <[email protected]> wrote:
> On Fri, Aug 19, 2016 at 10:07 AM, Yichao Yu <[email protected]> wrote: > >> >> >> On Fri, Aug 19, 2016 at 10:01 PM, Erik Schnetter <[email protected]> >> wrote: >> >>> On Fri, Aug 19, 2016 at 9:53 AM, Yichao Yu <[email protected]> wrote: >>> >>>> >>>> On Fri, Aug 19, 2016 at 9:01 PM, Oliver Schulz < >>>> [email protected]> wrote: >>>> >>>>> Hi Eric, >>>>> >>>>> nice - this is exactly what I meant. I wonder if Julia Symbols >>>>> themselves could become like this in the future. >>>>> >>>> >>>> As jameson said already, isbits or not is irrelevant here and we are >>>> working towards making non isbits type inlinable. >>>> >>>> The ValueSymbol type is also not a true isbits type, you can't save it >>>> to sysimg or use it with mmap array for example (well, you can, but you >>>> won't get the answer you want) >>>> >>> >>> Okay, call it `pointerfree` then. >>> >> >> Well, the point is that it doesn't have all the necessary probably >> assumed by other part of the system. `isbits` is an acronym of >> `pointerfree`. >> > > Can I mmap regular symbols? What ensures that the symbols' values are > contained in the mmapped region? What ensures that mmapped symbols are > unique with respect to local symbols? > No you can't and that's the point. You'll appears to be able to do that with a isbits symbol and get segfault. > > Saving in a system image is an operation for experts; there are > This includes package compilation > good solutions for ensuring symbols are stored and loaded properly, such > as e.g. serializing them. > Just to make it more clear, making symbols a bitstype will break many assumptions made everywhere in the system and only solve a problem that can be solved much better in other ways and also cause worse performance in many other cases. Important properties of isbits types * They can be transferred/saved as their bits content and still represent the same value. In another word, they are not pointers and doesn't hold references to other object. We do have C pointers, which violate this rule but we don't need to add another special case for pointers we can control. Performance advantage of bitstype * They don't need to be rooted This is actually one of the easiest optimization to implement in codegen. * They are stored inline and won't make the containing immutable a non-value type. This is the advantage everyone on this thread was talking about and the right way to solve this is to make !ptrfree immutable a value type (stack allocated, stored inline). Disadvantage of bitstype * They needs to be boxed in generic context, including jlcall and store to non-leaftype slot As listed above, making symbols bitstype is basically a temporary workaround before we flip the immutable layout. Other than that, it'll break many assumptions in the code (well, one assumption, used in many places) and cause performance regression in other cases.
