If Julia symbols are never garbage collected, then they could be directly implemented as a (bitstype) C pointer to a malloc'd region. There's no need to involve Julia's memory allocator or garbage collector, or tell the garbage collector about variables holding symbols.
-erik On Fri, Aug 19, 2016 at 9:01 AM, Oliver Schulz <oliver.sch...@tu-dortmund.de > wrote: > Hi Eric, > > nice - this is exactly what I meant. I wonder if Julia Symbols themselves > could become like this in the future. > > > Cheers, > > Oliver > > > On 17.08.2016 18:44, Erik Schnetter wrote: > >> See <https://github.com/eschnett/ValueSymbols.jl> for what I had in mind. >> >> -erik >> >> On Wed, Aug 17, 2016 at 10:32 AM, Yichao Yu <yyc1...@gmail.com >> <mailto:yyc1...@gmail.com>> wrote: >> >> >> >> On Wed, Aug 17, 2016 at 10:19 PM, Oliver Schulz >> <oliver.sch...@tu-dortmund.de <mailto:oliver.sch...@tu-dortmund.de>> >> wrote: >> >> Hi Yichao >> >> I get that - I was just curious why (and I guess there's likely >> a very good reason for it). My intuition would be that a >> non-GCed interned string type could be represented by a bitstype >> (i.e. a pointer or index to the string table). So I was >> surprised that Symbol is an object reference and wanted to >> understand this a bit better. >> >> >> It's a pointer to managed memory with tag that's all what's needed >> for it to be a !pointerfree type. There are way more things that we >> don't GC and it has nothing to do with whether it's a isbits type or >> not. >> >> >> >> >> Cheers, >> >> Oliver >> >> >> On Wednesday, August 17, 2016 at 3:35:41 PM UTC+2, Yichao Yu >> wrote: >> >> >> > PS: Yes, symbols in Julia should be bitstypes. >> >> No, it's a object reference and isn't a `isbits()` type. >> >> >> >> On Wed, Aug 17, 2016 at 8:26 AM, Cedric St-Jean >> <cedric...@gmail.com> wrote: >> >> Good points. >> >> Given that symbols have a name which is a string, I >> don't see how they could be a bits-type unless they >> just became numbers to index into a global array >> somewhere...... i.e. a pointer. Stack-allocating >> non-bits-type immutables is on the roadmap to 1.0, >> so that should solve your problems. >> >> Maybe you can solve the CategorizedPoint problem by >> using an @enum. >> >> On Wed, Aug 17, 2016 at 6:48 AM, Oliver Schulz >> <oliver...@tu-dortmund.de> wrote: >> >> Hello Andreas, >> >> consider iterating over a Dict{Symbol,Int64}: >> >> | >> d =Dict(:foo =>42,:bar =>77) >> forx ind println("$(typeof(x)), $(isbits(x))")end >> | >> >> >> During iteration, a lot of stack allocated >> "Pair{Symbol,Int64}" objects are created. That >> is very bad for performance. >> >> | >> immutable CategorizedPoint >> x::Float64 >> y::Float64 >> category::Symbol >> end >> | >> >> >> Also, consider a (hypothetical) data type for >> categorized points (with a finite number of >> categories - but extensible, so that Symbol is a >> better fit than using an enum): >> >> immutable CategorizedPoint >> x::Float64 >> y::Float64 >> category::Symbol >> end >> >> I would definitely want this to be a bits-type, >> and not have every instance heap-allocated. >> >> >> Cheers, >> >> Oliver >> >> >> On Wednesday, August 17, 2016 at 11:44:13 AM >> UTC+2, Andreas Lobinger wrote: >> >> Hello colleague, >> >> On Wednesday, August 17, 2016 at 11:12:51 AM >> UTC+2, Oliver Schulz wrote: >> >> Sure - I was assuming that as Symbol >> (as an interned string) is basically >> just a pointer. So comparisons are O(1), >> etc. What I'd like to understand is, why >> can't it be a bitstype? Currently, it's >> not, so Symbol cannot be used in a >> lightweight (i.e. stack-allocated) >> immutable type. I assume there's a good >> reason for it, I just want to understand >> why. >> >> >> Could you make an example how you would like >> to use Symbol in lightweight types? >> >> >> >> >> >> -- >> Erik Schnetter <schn...@gmail.com> >> http://www.perimeterinstitute.ca/personal/eschnetter/ >> <http://www.perimeterinstitute.ca/personal/eschnetter/> >> >> >> >> >> >> >> -- >> Erik Schnetter <schnet...@gmail.com <mailto:schnet...@gmail.com>> >> http://www.perimeterinstitute.ca/personal/eschnetter/ >> > > -- Erik Schnetter <schnet...@gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/
