decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
It is symbolic versus address, more than dynamic versus static | 400 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
The "definition" in another court document ruins this defence
Authored by: Anonymous on Sunday, May 13 2012 @ 01:06 AM EDT
I do worry a bit about the static vs dynamic meaning battle, because I can think
of at least one context wherein the term dynamic has been used in the field to
refer to resolution at load-time rather than run-time: shared object dynamically
linked libraries. My understanding of how this works in *IX for the typical
(non-dlopen) case is that there is a partial resolution that happens in the
linking phase (build-time), where the function references are resolved into
offsets in the shared library object file, and a final resolution that happens
at load-time wherein the library is loaded into shared memory if not already
present, and then the offset reference is resolved into a pointer to the actual
shared memory. (I may be butchering the explanation a bit here, it's been a long
time since my OS courses.)

In this case, the term 'dynamic' was chosen to distinguish from the old style of
'static linking' wherein the desired object code was copied directly into the
executable. There's another method of linking provided by calls like dlopen
which is more purely dynamic (all resolution happens purely at run-time) which
is suitable for things like plugin loading.

For as much as we try to be precise when labeling and referring to concepts,
there's a lot of context-specific variation in how CS people refer to things,
and a lot of terms like these are applied in a sense relative to how things were
done in earlier systems (there's no question that shared-object linking is far
less dynamic than dlopen, but it is arguably somewhat more dynamic than static
linking).

[ Reply to This | Parent | # ]

It is symbolic versus address, more than dynamic versus static
Authored by: Anonymous on Sunday, May 13 2012 @ 10:11 PM EDT

I notice that both responses to my comparison of the evidence to the previously ordered definition have focused too hard on dynamic versus static.

I am a programmer and I do know what the words usually means and how the concepts are usually implemented in practice, so please read my explanation more carefully, as I am being very technical here.

My main point was about what counts as symbolic. And in the context of this trial (only), "Symbolic" is defined as almost anything but the actual memory address. So the court may rule that a "symbol index" or "field index" as practiced by both the Sun JVM and the Google DalvikVM may count as a symbolic reference.

A key thing that these two virtual machines have, which older, saner instruction sets do not, is one or more special instructions or addressing modes where the instruction encoding explicitly says "The location with this yet-to-be- resolved-thing" and a different set of instructions or addressing modes where the instruction says "That location".

In contrast, most other instruction sets I have worked with have only an instruction form that says "That location", and then program file formats contain a separate "relocation table" listing the places where instructions need to have the offset or address field replaced by the resolved value of a symbol.

In traditional systems, the loader (if not the link loader before it) goes through the relocation table and fills in all the offsets and addresses before the program can be run, as the code would otherwise refer to the wrong memory locations (namely those indicated by whatever bit pattern is stored in the unresolved instructions, sometimes 0, sometimes some bits related to the relocation table).

In Java byte code and Dalvik word code, the extra instructions potentially allow unresolved references to remain in the running program without random bad effects. It is suggested, but might not be true, that if such an unresolved reference is left in the program by dexopt (or the JVM '104 mechanism), that the VM will do the lookup during instruction execution, which would satisfy the "dynamic" prong of the courts definition of "symbolic reference", unrelated to the issue of dexopt being static or dynamic itself.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )