Názory k článku Jak objekt ke štěstí přišel

A nebo pro lidi, co místo velmi dlouhého přemýšlení raději svěří kompilátoru takové věci, jako je escape analýza, lifetime analýza a jiné podobné roztomilosti, protože ten přemýšlí mnohem rychleji než by kdy dokázali oni sami, takže v důsledku zbyde na garbage collector jen docela malé množství objektů a ten tak nemá moc šancí nepříznivě ovlivnit výkon? ;-)

Tomu nerozumím; jak může kompilátor zastoupit garbage collector? To je nějaká aprílová habaďúra?

Ne všechna data, která jsou konceptuelně objekty objekty na heapu s přístupem přes reference ze stacku, jimi opravdu musejí být... ;-) (A to je jen ten nejjednodušší případ, se kterým se Java popere teprv teď. :-))

Jasně, ale pořád to moc nechápu. Dovedu si představit, že pokud někde v kódu je něco jako

Integer a
a = 1 + 1
print(a)

že si program nemusí vytvořit dvě instance třídy Integer, po sečtení ještě další, a pak její data zkopírovat do lokální proměnné a jenom proto, aby ve výsledku při každém volání metody vypsal "2" na obrazovku. Ale opravdu jsou podobné věci natolik typické, aby to ušetřilo garbage collectoru drtivou většinu práce?

Tak tady nebudou referencované objekty žádném rozumném jazyku, protože adresy se typicky alignují na celá slova, jsou tedy sudé a "liché adresy" jsou ve skutečnosti "integers by value", posunuté o něco doleva. Dokonce i kdyby to byly referencované objekty, nekopíroval by do lokální proměnné data, ale jen referenci. :-)

Třeba tady: http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html

Při troše snahy jde odbourat hodně abstrakcí, viz třeba Stalin... ;-)

Díky za odkaz, mrknu na to. S těmi celými čísly si určitě lze takto zašvindlovat, pokud víme jistě, že reprezentace celého čísla nepřeteče nad velikost toho přiděleného chlívku atd. Zejména u dynamických jazyků ale vidím dost potenciálních komplikací. Reference se kopírovat může, to je pravda.