Monday, February 21, 2011

java^c# generic -- struct, boxing, erasure

At the heart of all the jargon and debates lies one core issue -- field layout (FL). Essentially [1], field layout is what truly defines a type, be it class or struct.

For example, the java LinkedList's Node class has field layout to hold a payload and a "next-node" -- all pointers. Since untyped Node came to the scene first, Java generics resorted to type erasure (TE) for backward compatibility. As a result, Node of any payload is the same Node type at runtime. Consequently, LinkedList of any payload boils down to the same type. one-size-fit-all.

C# needs no TE. However, in a twist of clever design, Node of any reference payload has a field layout just like java. So LinkedList of any reference type boils down to the same type. Reduces code bloat.

vvv Java Node of int has to be boxed/unboxed because Node payload (like any reference type) must be a subtype of Object.java. Given a node, the compiler is /hardwired/ to treat the "payload" field therein as a pointer to the Heap (where boxed Integer lives).

^^^ C# Node of int is a distinct type with a distinct field layout.[2] The int value is a struct Instance embedded in Node object's real estate. No boxing/unboxing.
** Struct payloads are all treated this way.

This is yet another low-level technical issue affecting only high-performance, high volume market data and trading engines. Non-trading developers tend to consider this a niche that's "too" specialized.

See P156 [[c#precisely]]

[2] Incidentally, a Node of float has the same size as a Node of int, but compiler interprets the payload field as int vs float. Therefore different field layouts.
[1] This is practical thinking. I am no language lawyer. Specifically,
- A type can have only 1 field layout.
- If 2 types have identical field layout, then we can make one an alias of the other like a typedef. It's wasteful to create too many duplicate types.

No comments:

Total Pageviews

my favorite topics (labels)

_fuxi (302) _misLabel (13) _orig? (3) _rm (2) _vague (2) clarified (58) cpp (39) cpp_const (22) cpp_real (76) cpp/java/c# (101) cppBig4 (54) cppSmartPtr (35) cppSTL (33) cppSTL_itr (27) cppSTL_real (26) cppTemplate (28) creditMkt (14) db (65) db_sybase (43) deepUnder (31) dotnet (20) ECN (27) econ/bank` (36) fin/sys_misc (43) finGreek (34) finReal (45) finRisk (30) finTechDesign (46) finTechMisc (32) finVol (66) FixedIncom (28) fMath (7) fMathOption (33) fMathStoch (67) forex (39) gr8IV_Q (46) GTD_skill (15) GUI_event (30) inMemDB (42) intuit_math (41) intuitFinance (57) javaMisc (68) javaServerSide (13) lambda/delegate (22) marketData (28) math (10) mathStat (55) memIssue (8) memMgmt (66) metaProgram` (6) OO_Design (84) original_content (749) polymorphic/vptr (40) productive (21) ptr/ref (48) py (28) reflect (8) script`/unix (82) socket/stream (39) subquery/join (30) subvert (13) swing/wpf (9) sysProgram` (16) thread (164) thread_CAS (15) thread_cpp (28) Thread* (22) timeSaver (80) transactional (23) tune (24) tuneDB (40) tuneLatency (30) z_ajax (9) z_algoDataStruct (41) z_arch (26) z_arch_job (27) z_automateTest (17) z_autoTrad` (19) z_bestPractice (39) z_bold (83) z_bondMath (35) z_book (18) z_boost (19) z_byRef^Val (32) z_c#GUI (43) z_c#misc (80) z_cast/convert (28) z_container (67) z_cStr/arr (39) z_Favorite* (8) z_FIX (15) z_forex (48) z_fwd_Deal (18) z_gz=job (33) z_gzBig20 (13) z_gzMgr (13) z_gzPain (20) z_gzThreat (19) z_hib (19) z_IDE (52) z_ikm (5) z_IR_misc (36) z_IRS (26) z_javaWeb (28) z_jdbc (10) z_jobFinTech (46) z_jobHunt (20) z_jobRealXp (10) z_jobStrength (15) z_jobUS^asia (27) z_letter (42) z_linq (10) z_memberHid` (11) z_MOM (54) z_nestedClass (5) z_oq (24) z_PCP (12) z_pearl (1) z_php (20) z_prodSupport (7) z_py (31) z_quant (14) z_regex (8) z_rv (38) z_skillist (48) z_slic`Problem (6) z_SOA (14) z_spring (25) z_src_code (8) z_swingMisc (50) z_swingTable (26) z_unpublish (2) z_VBA/Excel (8) z_windoz (17) z_wpfCommand (9)

About Me

New York (Time Square), NY, United States
http://www.linkedin.com/in/tanbin