An

expressive

aspect

language

for

system

applications

with

Arachne

C

applications

in

particular

those

using

operating

system

level

services

frequently

comprise

multiple

crosscutting

concerns

network

protocols

and

security

are

typical

examples

of

such

concerns

While

these

concerns

can

partially

be

addressed

during

design

and

implementation

of

an

application

they

frequently

become

an

issue

at

runtime

e.g.

to

avoid

server

downtime

A

deployed

network

protocol

might

not

be

efficient

enough

and

may

thus

need

to

be

replaced

Buffer

overflows

might

be

discovered

that

imply

critical

breaches

in

the

security

model

of

an

application

A

prefetching

strategy

may

be

required

to

enhance

performance

While

aspect-oriented

programming

seems

attractive

in

this

context

of

the

current

aspect

systems

is

expressive

and

efficient

enough

to

address

such

concerns

This

paper

presents

a

new

aspect

system

to

provide

a

solution

to

this

problem

While

efficiency

considerations

have

played

an

important

part

in

the

design

of

the

aspect

language

the

language

allows

aspects

to

be

expressed

more

concisely

than

previous

approaches

In

particular

it

allows

aspect

programmers

to

quantify

over

sequences

of

execution

points

as

well

as

over

accesses

through

variable

aliases

We

show

how

the

former

can

be

used

to

modularize

the

replacement

of

network

protocols

and

the

latter

to

prevent

buffer

overflows

We

also

present

an

implementation

of

the

language

as

an

extension

of

Arachne

a

dynamic

weaver

for

C

applications

Finally

we

present

performance

evaluations

supporting

that

Arachne

is

fast

enough

to

extend

high

performance

applications

such

as

the

Squid

web

cache

Permission

to

make

digital

or

hard

copies

of

all

or

part

of

this

work

for

personal

or

classroom

use

is

granted

without

fee

provided

that

copies

are

not

made

or

distributed

for

profit

or

commercial

advantage

and

that

copies

bear

this

notice

and

the

full

citation

on

the

first

page

To

copy

otherwise

to

republish

to

post

on

servers

or

to

redistribute

to

lists

requires

prior

specific

permission

and/or

a

fee

AOSD

Chicago

Illinois

USA

Copyright

ACM

Real-world

applications

typically

comprise

multiple

crosscutting

concerns

This

applies

in

particular

to

C

applications

using

operating

system

level

services

We

have

exam-ined

three

concerns

which

are

typical

for

this

domain

in

the

context

of

a

large

application

the

open

source

web

cache

Squid

-LSB-

-RSB-

More

concretely

we

have

considered

translation

of

network

protocols

-LRB-

which

may

be

necessary

for

efficiency

reasons

-RRB-

insertion

of

checks

for

buffer

overflows

-LRB-

which

are

at

the

heart

of

many

of

today

's

security

issues

-RRB-

and

introduction

of

prefetching

strategies

within

the

cache

-LRB-

which

can

be

used

to

enhance

efficiency

of

the

web

cache

-RRB-

We

have

found

that

all

these

concerns

are

scattered

over

large

portions

of

the

code

of

Squid

Hence

the

three

concerns

are

crosscutting

in

the

sense

of

Aspect-Oriented

Programming

-LRB-

AOP

-RRB-

-LSB-

-RSB-

and

aspects

should

therefore

be

a

means

of

choice

for

their

modularization

The

concerns

have

three

important

characteristics

First

they

must

frequently

be

applied

at

runtime

e.g.

in

order

to

rapidly

fix

a

buffer

overflow

and

thus

prevent

security

breaches

without

incurring

server

downtime

A

dynamic

aspect

weaver

is

therefore

needed

Second

they

expose

intricate

relationships

between

execution

points

e.g.

network

protocols

are

most

concisely

expressed

in

terms

of

sequences

of

execution

points

not

individual

ones

The

aspect

system

must

therefore

support

expressive

means

for

the

definition

of

aspects

in

particular

pointcuts

Third

efficiency

is

crucial

in

the

application

domain

we

consider

To

our

knowledge

of

the

current

aspect

systems

for

C

meet

these

three

requirements

and

is

suitable

for

the

modularization

of

such

concerns

Moreover

requirements

for

dynamic

weaving

and

efficiency

often

trade

off

with

expressivity

Squid

should

be

as

efficient

as

possible

and

therefore

exploit

any

suitable

operating

system

and

hardware

particularity

Its

code

base

is

therefore

difficult

to

understand

and

manipulate

thus

hindering

in

particular

modularization

efforts

It

is

therefore

highly

questionable

that

the

considered

modularization

problems

can

be

solved

without

aspects

In

this

paper

we

propose

a

solution

to

the

aspectization

of

such

concerns

of

C

applications

More

concretely

we

provide

three

main

contributions

First

we

provide

a

new

expressive

aspect

language

featuring

a

construct

for

quantification

over

sequences

of

execution

points

as

well

as

over

accesses

to

local

aliases

of

global

variables

We

show

how

this

aspect

guage

permits

concise

expression

of

the

considered

concerns

as

aspects

Second

we

present

how

the

aspect

language

can

be

implemented

efficiently

through

runtime

weaving

into

binary

code

Concretely

this

is

done

by

integrating

the

aspect

language

into

our

tool

Arachne

a

dynamic

weaver

for

C

applications

Furthermore

we

present

how

Arachne

improves

on

our

previous

work

Dyner

-LSB-

-RSB-

Finally

we

give

evidence

that

our

approach

meets

strong

efficiency

requirements

by

showing

performance

evaluations

in

the

context

of

Squid

The

paper

is

structured

as

follows

Section

presents

the

motivating

concerns

we

identified

within

Squid

Section

shows

how

to

modularize

these

concerns

as

aspects

and

defines

our

aspect

language

Section

describes

its

implementation

within

Arachne

Section

assesses

the

performance

of

our

implementation

Section

describes

related

work

Section

concludes

and

suggests

futures

work

Legacy

C

applications

involve

multiple

crosscutting

concerns

Many

of

them

remain

challenging

both

in

terms

of

expressiveness

required

to

handle

them

properly

in

an

aspect-oriented

language

and

in

terms

of

constraints

posed

on

the

weaver

This

section

describes

three

such

concerns

in

C

applications

switching

the

network

protocol

buffer

overflows

and

prefetching

The

network

protocol

concern

is

typically

scattered

through

the

entire

application

It

is

an

issue

when

administrators

discover

at

runtime

that

the

retained

protocol

is

not

efficient

enough

Likewise

the

security

threats

posed

by

buffer

overflows

is

a

real

concrete

problem

for

administrators

While

guarding

all

buffers

against

overflows

might

decrease

performance

considerably

administrators

are

left

with

no

other

option

than

accepting

the

trade-off

between

security

and

performance

chosen

at

application

's

design

time

Prefetching

is

another

well-known

crosscutting

concern

-LSB-

-RSB-

Since

prefetching

aims

at

increasing

performance

prefetching

aspects

make

only

sense

with

an

efficient

weaver

Yet

it

is

still

difficult

to

modularize

these

three

concerns

in

today

's

aspect-oriented

language

In

this

section

we

first

describe

the

context

in

which

the

concerns

arise

before

showing

their

crosscutting

nature

and

finally

explaining

the

lack

in

current

aspect-oriented

languages

to

handle

them

properly

TCP

to

UDP

protocol

HTTP

was

essentially

designed

as

a

file

transfer

protocol

running

on

top

of

TCP

a

connection-oriented

protocol

ensuring

communication

reliability

While

the

average

Web

page

size

does

not

exceed

KB

-LSB-

-RSB-

the

cost

of

retrieving

a

Web

page

is

often

dominated

by

data

exchanged

for

control

purposes

of

TCP

rather

than

by

the

page

content

itself

This

is

not

a

new

problem

many

researches

have

already

pointed

out

that

TCP

is

not

suitable

for

short-lived

connections

While

HTTP

has

introduced

persistent

connections

allowing

a

client

to

retrieve

multiple

pages

from

the

same

server

through

the

same

TCP

connection

the

number

of

simultaneous

TCP

connections

is

limited

by

operating

systems

Servers

have

a

strong

incentive

to

close

HTTP

connections

as

soon

as

possible

Hence

despite

the

persistent

connection

mechanism

many

studies

conclude

that

TCP

should

be

replaced

by

UDP

to

retrieve

short

pages

-LSB-

-RSB-

In

spite

of

its

performance

improvements

the

number

of

legacy

Web

applications

has

prevented

a

wide

adoption

of

this

solution

Typical

legacy

Web

applications

have

to

be

listen

accept

read

write

close

write

read

close

connect

socket

Server

Client

TCP

Protocol

socket

bind

close

close

socket

Server

Client

UDP

Protocol

recvfrom

sendto

recvfrom

socket

bind

Network

Network

sendto

Time

Figure

Typical

usage

of

the

TCP

and

UDP

APIs

stopped

to

switch

the

protocol

The

traditional

approach

to

avoid

depriving

a

subnetwork

from

Internet

connectivity

while

stopping

the

cache

is

to

swap

the

application

between

different

machines

This

approach

is

not

only

expensive

in

terms

of

hardware

it

complicates

the

administrative

task

of

the

Web

cache

administrator

and

poses

the

problem

of

con-sistently

transferring

the

runtime

state

of

the

application

before

restarting

it

Stopping

an

e-commerce

Web

server

means

a

loss

of

money

and

many

small

companies

can

not

afford

the

cost

of

redundant

servers

For

a

wide

acceptance

a

HTTP

dialect

using

UDP

as

transport

protocol

should

thus

be

deployable

on

demand

at

runtime

In

addition

replacing

TCP

by

UDP

in

an

application

is

relatively

difficult

The

choice

of

a

transport

protocol

is

usually

based

on

standards

believed

to

be

ever-lasting

and

made

at

an

early

design

stage

Hence

no

particular

effort

is

made

to

localize

this

design

decision

in

a

single

piece

of

code

For

example

despite

a

modularization

effort

the

TCP

API

provided

by

the

operating

system

is

used

directly

in

of

the

c

source

files

of

the

Squid

Web

cache

As

shown

in

Fig.

the

TCP

API

is

built

around

a

set

of

C

functions

to

be

invoked

sequentially

by

the

application

In

a

properly

written

program

TCP

functions

are

first

used

to

establish

the

connection

-LRB-

typically

with

socket

connect

bind

and

listen

-RRB-

exchange

data

through

the

connection

-LRB-

typically

with

read

and

write

-RRB-

and

then

close

it

-LRB-

typically

close

-RRB-

UDP

uses

similar

but

less

functions

UDP

applications

first

direct

the

operating

system

to

dedicate

the

appropriate

resources

to

exchange

data

-LRB-

typically

with

socket

and

bind

-RRB-

then

exchange

data

through

these

resources

-LRB-

typically

with

sendto

and

recvfrom

-RRB-

before

releasing

them

-LRB-

typically

with

close

-RRB-

Hence

the

problem

is

not

only

difficult

because

TCP-related

function

invocations

are

scattered

but

because

the

relative

order

of

each

invocation

is

important

in

order

to

map

it

onto

the

appropriate

UDP

function

This

example

is

typical

of

protocol

based

APIs

When

such

an

API

is

used

in

an

undisciplined

way

it

becomes

quickly

impossible

to

replace

it

by

another

one

Today

aspect-oriented

systems

lack

an

appropriate

sequencing

construct

in

their

language

Moreover

many

do

not

provide

the

ability

to

weave

aspects

dynamically

Buffer

overflows

In

C

the

size

of

an

array

is

fixed

at

allocation

time

According

to

ISO

and

ANSI

standards

-LSB-

-RSB-

an

invalid

array

access

does

not

result

in

an

immediate

error

but

leads

to

an

implementation-dependent

behavior

Such

behavior

is

increasingly

exploited

by

hackers

to

circumvent

security

strictions

-LSB-

-RSB-

It

is

therefore

crucial

for

C

programmers

to

ensure

every

access

to

an

array

to

be

valid

On

the

other

hand

bound

checking

code

is

error

prone

it

is

easy

to

forget

to

check

an

access

and

even

when

the

access

is

checked

it

is

easy

to

compare

the

index

locating

the

access

with

an

inappropriate

bound

Therefore

researchers

have

proposed

to

make

compilers

responsible

for

enforcing

proper

array

access

-LSB-

-RSB-

The

problem

is

that

even

the

most

efficient

system

-LRB-

CRED

-LSB-

-RSB-

-RRB-

slows

down

an

application

up

to

Moreover

most

frequently

used

compilers

like

gcc

do

not

support

bound

checking

Today

administrators

discovering

a

buffer

overflow

in

production

software

are

left

with

no

other

option

than

stopping

the

application

and

restarting

a

bug

free

version

This

was

the

solution

chosen

when

a

buffer

overflow

was

discovered

in

Squid

in

-LSB-

-RSB-

While

widely

used

this

solution

suffers

from

three

major

drawbacks

First

it

does

not

enforce

continuous

servicing

since

the

service

delivered

by

the

application

is

not

available

during

the

update

Second

this

solution

entails

an

important

information

loss

an

administrator

has

no

means

to

learn

whether

the

buffer

overflow

has

been

exploited

by

a

hacker

or

not

Third

it

misunderstands

the

performance

trade-off

i.e.

it

is

not

necessary

to

check

every

array

access

it

is

only

necessary

to

perform

enough

checking

to

discourage

hackers

Therefore

bound

checking

code

should

only

run

when

an

environment

becomes

hostile

-LSB-

-RSB-

Bound

checking

code

tends

to

crosscut

the

entire

application

For

example

properly

written

C

functions

accepting

an

array

argument

commonly

take

a

second

argument

holding

the

array

size

the

first

one

allows

the

function

to

access

the

array

while

the

second

is

used

to

ensure

correctness

of

accesses

In

Squid

bound

checking

code

can

be

found

in

any

of

the

c

files

of

its

source

code

On

the

lines

composing

these

c

files

at

least

check

bounds

This

problem

fails

to

be

handled

properly

in

current

aspect

languages

as

they

lack

the

ability

to

trigger

advices

upon

access

made

through

the

alias

of

a

variable

Again

many

aspect-oriented

systems

offer

only

static

weaving

capabilities

preventing

the

administrator

to

choose

the

trade-off

security/performance

suiting

his

needs

From

fetching

to

prefetching

Operations

like

retrieving

a

file

on

a

local

disk

or

over

the

Web

can

be

sped

up

if

the

underlying

software

anticipates

user

requests

and

start

to

fetch

documents

beforehand

Such

prefetching

schemes

distinguish

themselves

from

each

other

in

the

way

they

predict

future

user

requests

These

ora-cles

actually

prevent

a

clean

encapsulation

of

prefetching

in

a

single

module

communicating

with

the

rest

of

the

application

through

well-defined

interfaces

since

predictions

are

based

on

information

meant

to

be

private

to

other

modules

In

addition

it

is

very

likely

that

there

is

no

universal

perfect

oracle

-LSB-

-RSB-

A

statically

linked

prefetching

module

is

therefore

inappropriate

but

prefetching

modules

along

with

the

necessary

oracles

should

be

loaded

and

unloaded

on

the

fly

Due

to

their

crosscutting

nature

prefetching

modules

including

such

oracles

are

better

written

with

aspects

-LSB-

-RSB-

Coady

et

al.

have

already

pointed

out

the

crosscutting

nature

of

prefetching

in

the

FreeBSD

OS

-LSB-

-RSB-

In

our

previous

work

considering

the

Squid

Web

cache

we

reached

a

similar

conclusion

-LSB-

-RSB-

We

have

previously

shown

that

this

concern

can

be

addressed

with

cflow-like

constructs

Despite

potential

performance

improvements

prefetching

also

increases

resource

consumption

-LRB-

e.g.

network

prefetching

consumes

local

storage

and

bandwidth

-RRB-

When

the

pressure

on

resources

is

too

high

prefetching

computation

competes

for

them

against

regular

user

requests

and

slows

down

their

treatment

instead

of

speeding

it

up

In

such

cases

prefetching

should

therefore

be

temporarily

disabled

Squid

essentially

manages

file

descriptors

a

resource

only

available

in

a

limited

quantity

A

file

descriptor

is

used

between

the

underlying

operating

system

and

applications

to

describe

a

network

connection

or

a

file

on

the

disk

Squid

's

file

descriptor

management

is

based

on

a

global

variable

that

tracks

the

number

of

file

descriptors

currently

in

use

By

comparing

its

value

with

the

maximum

number

of

file

descriptors

allowed

by

the

operating

system

it

is

possible

to

estimate

that

prefetching

should

be

disabled

or

resumed

For

this

problem

of

file

descriptor

consumption

the

current

practice

of

checking

if

prefetching

should

be

disabled

or

not

within

the

advice

is

a

bad

practice

that

impedes

both

readability

and

maintainability

A

mechanism

is

needed

within

the

aspect

language

to

restraint

the

advice

execution

at

times

where

the

pressure

on

resources

is

too

high

This

problem

were

not

addressed

in

our

previous

work

While

AOP

seems

to

be

the

obvious

choice

to

tackle

the

crosscutting

concerns

introduced

above

of

the

existing

AO

systems

provides

explicit

support

for

some

of

their

essential

elements

in

particular

join

point

sequences

for

protocols

and

references

to

aliases

which

are

local

to

a

function

In

this

section

we

introduce

a

new

aspect

language

for

system

programming

in

C

that

allows

such

crosscutting

concerns

to

be

expressed

concisely

In

order

to

make

this

point

we

first

revisit

the

examples

by

concisely

aspectizing

them

using

our

language

-LRB-

Note

that

our

aspect

language

is

expressive

in

the

sense

of

enabling

the

concise

definition

of

certain

types

of

aspects

especially

compared

to

other

tools

for

system-level

manipulations

but

not

necessarily

more

expressive

than

existing

approaches

in

a

language-theoretic

sense

-RRB-

We

then

define

the

join

point

model

underlying

our

language

precisely

followed

by

the

definition

of

its

syntax

and

informal

semantics

Finally

we

illustrate

how

its

semantics

can

be

formally

defined

in

terms

of

a

small-step

operational

semantics

using

the

framework

introduced

in

-LSB-

-RSB-

Example

crosscutting

concerns

revisited

We

now

revisit

the

concerns

discussed

in

section

in

order

to

show

our

language

in

action

and

give

evidence

that

it

allows

such

concerns

to

be

concisely

modularized

The

aspect

shown

in

Fig.

translates

transport

protocols

from

TCP

to

UDP

A

protocol

defines

a

sequence

of

function

calls

so

the

top-level

operator

of

this

aspect

is

seq.

The

sequence

aspect

syntactically

consists

of

a

list

of

pairs

of

pointcut

and

advice

-LRB-

separated

by

then

-RRB-

In

the

example

the

TCP

protocol

starts

with

a

call

to

socket

-LRB-

-RRB-

with

three

constant

arguments

AF

INET

SOCK

STREAM

and

When

such

a

call

is

matched

the

second

parameter

is

replaced

by

SOCK

DGRAM

as

required

by

the

UDP

protocol

The

result

of

this

transformed

call

the

file

descriptor

is

bound

to

fd

by

return

-LRB-

fd

-RRB-

Then

the

next

call

to

connect

-LRB-

-RRB-

with

the

same

file

descriptor

fd

as

its

first

parameter

is

matched

In

this

case

the

values

of

the

other

parameters

seq

-LRB-

call

-LRB-

int

socket

-LRB-

int

int

int

-RRB-

-RRB-

args

-LRB-

AF

INET

SOCK

STREAM

-RRB-

return

-LRB-

fd

-RRB-

then

socket

-LRB-

AF

INET

SOCK

DGRAM

-RRB-

call

-LRB-

int

connect

-LRB-

int

struct

socketaddr

socklen

t

-RRB-

-RRB-

args

-LRB-

fd

address

length

-RRB-

then

returnZero

-LRB-

-RRB-

where

int

returnZero

-LRB-

-RRB-

-LCB-

return

-RCB-

-LRB-

call

-LRB-

size

t

read

-LRB-

int

void

size

t

-RRB-

-RRB-

args

-LRB-

fd

readBuffer

readLength

-RRB-

then

recvfrom

-LRB-

fd

readBuffer

readLength

address

length

-RRB-

call

-LRB-

size

t

write

-LRB-

int

void

size

t

-RRB-

-RRB-

args

-LRB-

fd

writeBuffer

writeLength

-RRB-

then

sendto

-LRB-

fd

writeBuffer

writeLength

address

length

-RRB-

-RRB-

call

-LRB-

int

close

-LRB-

int

-RRB-

-RRB-

args

-LRB-

fd

-RRB-

-RRB-

Figure

An

Aspect

for

Switching

Transport

Protocols

from

TCP

to

UDP

seq

-LRB-

call

-LRB-

void

malloc

-LRB-

size

t

-RRB-

-RRB-

args

-LRB-

allocatedSize

-RRB-

return

-LRB-

buffer

-RRB-

write

-LRB-

buf

f

er

-RRB-

size

-LRB-

writtenSize

-RRB-

if

-LRB-

writtenSize

allocatedSize

-RRB-

then

reportOverflow

-LRB-

-RRB-

call

-LRB-

void

free

-LRB-

void

-RRB-

-RRB-

-RRB-

Figure

An

Aspect

for

Detecting

Buffer

Overflow

are

bound

to

arguments

address

and

length

and

the

original

call

is

replaced

by

returnZero

-LRB-

-RRB-

Indeed

there

is

no

connect

step

in

the

UDP

protocol

After

that

calls

to

read

-LRB-

-RRB-

and

write

-LRB-

-RRB-

-LRB-

using

the

or

on

aspects

-RRB-

on

the

same

file

descriptor

fd

are

translated

to

UDP

recvfrom

-LRB-

-RRB-

and

sendto

-LRB-

-RRB-

respectively

Note

that

sequences

of

such

access

are

potentially

translated

-LRB-

due

to

use

of

the

repetition

operator

-RRB-

Finally

a

call

to

close

-LRB-

-RRB-

on

fd

terminates

the

TCP

protocol

as

well

as

the

UDP

protocol

and

thus

is

not

modified

-LRB-

i.e.

there

is

no

then

clause

-RRB-

This

last

step

is

required

to

free

the

variables

used

in

the

sequence

-LRB-

here

fd

address

and

length

-RRB-

Indeed

this

aspect

can

use

numerous

-LRB-

instances

of

these

-RRB-

variables

when

it

deals

with

interleaved

sequences

as

each

call

to

socket

-LRB-

-RRB-

creates

a

new

instance

of

the

sequence

The

aspect

shown

in

Fig.

detects

buffer

overflows

The

corresponding

sequence

starts

when

the

function

malloc

-LRB-

-RRB-

returns

the

buffer

address

which

is

then

bound

to

buffer

Then

each

time

this

address

is

accessed

-LRB-

through

a

global

variable

or

a

local

alias

-RRB-

the

size

of

the

data

to

be

written

is

compared

with

the

size

of

the

initially

allocated

memory

If

the

former

exceeds

the

latter

an

overflow

is

indicated

The

sequence

ends

when

the

memory

is

deallocated

using

free

-LRB-

-RRB-

The

aspect

in

Fig.

introduces

prefetching

in

a

web

cache

The

first

controlflow

phrase

initializes

prefetching

when

an

HTTP

response

is

built

-LRB-

clientBuildReply

-LRB-

-RRB-

-RRB-

within

the

control

flow

of

a

client

request

-LRB-

clientSendMoreData

-LRB-

-RRB-

-RRB-

The

until

clause

stops

prefetching

when

the

number

of

connection

becomes

too

large

a

situation

where

prefetching

would

effectively

degrade

performance

The

second

controlflow

phrase

analyzes

hyperlinks

in

a

page

being

transmitted

-LRB-

i.e.

when

comm

write

mbuf

-LRB-

-RRB-

is

called

within

the

control

flow

of

clientSendMoreData

-LRB-

-RRB-

-RRB-

Finally

the

last

call

phrase

pre-fetches

hyperlinks

analyzed

by

the

second

aspect

It

does

so

by

replacing

the

method

call

to

clientWriteComplete

-LRB-

-RRB-

with

retrieveHyperlinks

-LRB-

-RRB-

Finally

note

that

the

two

require

clauses

at

the

top

of

the

aspect

declare

the

types

of

the

global

variables

of

the

base

program

used

in

the

aspects

Join

points

A

join

point

model

defines

the

points

in

the

execution

of

the

base

program

to

which

pointcuts

may

refer

In

our

JP

callJP

-LRB-

val

funId

-LRB-

val

-RRB-

-RRB-

readGlobalJP

-LRB-

varId

val

-RRB-

readJP

-LRB-

val

-RRB-

writeGlobalJP

-LRB-

varId

val

size

-RRB-

writeJP

-LRB-

val

size

-RRB-

controlflowJP

-LRB-

f

unId

cfEnd

-RRB-

controlflowstarJP

-LRB-

f

unId

cfEnd

-RRB-

cf

End

callJP

-LRB-

val

funId

-LRB-

val

-RRB-

-RRB-

readGlobalJP

-LRB-

varId

val

-RRB-

writeGlobalJP

-LRB-

varId

val

size

-RRB-

val

int

int

values

of

other

C

types

Figure

Join

point

model

case

join

points

are

defined

by

JP

in

the

grammar

shown

in

Fig.

A

join

point

is

either

A

call

of

a

function

callJP

-LRB-

v

funId

-LRB-

v

-RRB-

-RRB-

with

function

name

funId

return

value

v

and

a

vector

of

arguments

v

A

read

access

which

comes

in

two

variants

readGlobalJP

-LRB-

varId

v

-RRB-

denotes

reading

a

global

variable

with

name

varId

holding

the

value

v

readJP

-LRB-

v

-RRB-

denotes

reading

a

global

variable

or

a

local

alias

with

address

holding

the

value

v

Write

access

which

also

comes

in

two

variants

writeGlobalJP

-LRB-

varId

v

size

-RRB-

denotes

assignment

to

a

global

variable

with

name

varId

of

the

value

v

of

size

size

writeJP

-LRB-

v

size

-RRB-

denotes

assignment

to

a

global

variable

or

a

local

alias

with

address

of

the

value

v

of

size

size

A

cflow

expression

controlflowJP

-LRB-

f

unId

c

-RRB-

where

f

unId

-LSB-

funId

funId

n

-RSB-

is

a

stack

of

function

names

and

c

-LRB-

either

a

function

call

or

an

access

to

a

global

variable

-RRB-

occurs

within

the

body

of

function

f

unId

n

Such

a

join

point

requires

a

call

to

f

unId

i

within

the

body

of

f

unId

i

A

cflow

expression

controlflowstarJP

-LRB-

f

unId

c

-RRB-

where

f

unId

-LSB-

funId

funId

n

-RSB-

is

a

partial

stack

of

function

names

and

c

-LRB-

either

a

function

call

or

an

access

to

a

global

variable

-RRB-

occurs

within

the

control

flow

of

function

f

unId

n

Such

a

join

point

requires

a

call

to

f

unId

i

within

the

control

flow

of

-LRB-

i.e.

not

necessarily

in

the

body

of

-RRB-

f

unId

i

Two

features

of

this

join

point

model

may

be

surprising

at

first

sight

distinction

of

accesses

to

aliases

from

those

to

global

variables

and

explicit

representation

of

control

flow

require

N

umber

Of

F

d

as

int

require

Squid

M

axF

d

as

int

controlflow

-LRB-

call

-LRB-

void

clientSendMoreData

-LRB-

void

char

size

t

-RRB-

-RRB-

call

-LRB-

HttpReply

clientBuildReply

-LRB-

clientHttpRequest

char

size

t

-RRB-

-RRB-

args

-LRB-

request

buf

f

er

buf

f

erSize

-RRB-

-RRB-

then

startPrefetching

-LRB-

request

buffer

bufferSize

-RRB-

until

-LRB-

writeGlobal

-LRB-

int

N

umber

Of

F

d

-RRB-

if

-LRB-

-LRB-

N

umber

Of

F

d

-RRB-

-LRB-

Squid

M

axF

d

-RRB-

-RRB-

-RRB-

controlflow

-LRB-

call

-LRB-

void

clientSendMoreData

-LRB-

void

char

size

t

-RRB-

-RRB-

call

-LRB-

void

comm

write

mbuf

-LRB-

int

MemBuf

void

void

-RRB-

-RRB-

args

-LRB-

fd

mb

handler

handlerData

-RRB-

if

-LRB-

isP

ref

etch

-LRB-

handler

-RRB-

-RRB-

-RRB-

then

parseHyperlinks

-LRB-

fd

mb

handler

handlerData

-RRB-

call

-LRB-

void

clientWriteComplete

-LRB-

int

char

size

t

int

void

-RRB-

-RRB-

args

-LRB-

fd

buf

size

error

data

-RRB-

if

-LRB-

isP

ref

etch

-LRB-

handler

-RRB-

-RRB-

then

retrieveHyperlinks

-LRB-

fd

buf

size

error

data

-RRB-

Figure

An

Aspect

for

Prefetching

expressions

Both

are

motivated

by

our

quest

for

efficiency

and

are

grounded

in

strong

implementation

constraints

in

the

context

of

dynamic

weaving

of

binary

C

code

an

access

to

a

local

alias

is

several

magnitudes

slower

than

that

to

a

global

variable

and

matching

of

control

flow

join

points

can

be

done

using

an

atomic

test

on

the

implementation

level

Pointcuts

We

now

present

a

pointcut

language

-LRB-

see

Fig.

-RRB-

that

provides

constructs

to

match

individual

join

points

Primitive

pointcuts

are

defined

by

PPrim

and

comprise

three

basic

pointcuts

matching

calls

global

variable

accesses

and

control

flow

join

points

Primitive

pointcuts

can

also

be

combined

using

a

logical

or

noted

A

call

pointcut

PCall

selects

all

function

call

join

points

callJP

-LRB-

val

funId

-LRB-

val

-RRB-

-RRB-

i.e.

all

calls

to

a

function

matching

the

signature

type

funId

-LRB-

type

-RRB-

where

the

arguments

of

the

function

can

be

bound

to

pointcut

variables

using

argument

binder

args

-LRB-

pattern

-RRB-

and

the

return

value

can

be

bound

to

a

pointcut

variable

using

a

return

clause

return

-LRB-

pattern

-RRB-

The

two

constructs

args

-LRB-

pattern

-RRB-

and

return

-LRB-

pattern

-RRB-

can

also

provide

pattern

matching

by

using

values

-LRB-

or

already

bound

pointcut

variables

-RRB-

in

pattern

Pointcuts

can

also

depend

on

a

boolean

condition

using

the

if-constructor

A

global

access

pointcut

PAccGlobal

selects

either

all

read

join

points

readGlobalJP

-LRB-

varId

val

-RRB-

or

all

write

join

points

writeGlobalJP

-LRB-

varId

val

size

-RRB-

on

the

global

base

program

variable

varId

In

these

cases

the

read

or

written

value

can

be

bound

to

a

variable

using

value

-LRB-

pattern

-RRB-

in

addition

the

size

of

the

written

value

can

be

bound

with

size

-LRB-

varName

-RRB-

Pattern

matching

can

also

be

used

for

variable

access

A

control

flow

pointcut

PCf

of

the

form

controlflow

-LRB-

PCallSig

PCallSig

n

PCfEnd

-RRB-

matches

all

join

points

of

the

form

controlflowJP

-LRB-

funId

funId

n

cfEnd

-RRB-

where

the

function

identifier

in

P

CallSig

i

is

f

unId

i

Similarly

a

control

flow

pointcut

may

match

a

global

variable

access

for

a

given

stack

configuration

The

pointcuts

of

the

form

controlflowstar

-LRB-

-RRB-

select

calls

or

global

variable

accesses

in

a

stack

context

allowing

for

calls

that

are

not

directly

nested

within

one

another

Finally

P

Acc

an

access

pointcut

for

a

global

variable

or

all

of

its

local

aliases

matches

all

join

points

of

the

form

readJP

or

writeJP

Asp

AspP

rim

-LSB-

until

-LRB-

AspP

rim

-RRB-

-RSB-

AspSeq

-LSB-

until

-LRB-

AspP

rim

-RRB-

-RSB-

AspP

rim

P

P

rim

Advice

AspSeq

seq

-LRB-

AspP

rim

AspSeqElts

AspSeqElt

-RRB-

AspSeqElts

-LSB-

AspSeqElts

-RSB-

AspSeqElt

-LSB-

-RSB-

AspSeqElt

AspP

rim

P

Acc

Advice

-LRB-

AspSeqElt

AspSeqElt

-RRB-

Advice

-LSB-

then

f

unId

-LRB-

pattern

-RRB-

-RSB-

Figure

Aspect

language

Aspect

Language

The

aspect

language

we

propose

is

defined

in

Fig.

Aspects

Asp

are

either

primitive

AspP

rim

or

sequences

of

primitive

aspects

AspSeq

A

primitive

aspect

AspPrim

combines

a

primitive

pointcut

with

an

advice

that

will

be

applied

to

all

join

points

selected

by

the

pointcut

If

the

primitive

pointcut

has

the

form

p

p

then

all

variables

used

in

the

advice

have

to

be

bound

in

both

p

and

p

An

advice

-LRB-

Advice

-RRB-

is

a

C

function

call

that

replaces

a

join

point

in

the

base

program

execution

-LRB-

similarly

to

around

in

AspectJ

-RRB-

It

must

have

the

same

return

type

as

the

join

point

it

replaces

the

type

of

the

global

variable

in

case

of

a

read

access

void

for

a

write

access

and

the

return

type

of

the

function

for

a

call

When

the

advice

is

empty

-LRB-

no

then

clause

-RRB-

the

original

join

point

is

executed

The

original

join

point

can

be

skipped

by

calling

an

empty

C

function

A

sequence

aspect

is

composed

of

a

sequence

of

primitive

aspects

A

sequence

starts

when

the

first

primitive

aspect

matches

Then

the

second

primitive

aspect

becomes

active

instead

of

the

first

one

When

it

matches

the

third

aspect

becomes

active

instead

of

the

second

one

And

so

on

until

the

last

primitive

aspect

in

the

sequence

All

but

the

first

and

last

primitive

aspects

can

be

repeated

zero

or

multiple

times

by

using

in

this

case

the

primitive

aspect

is

P

P

rim

P

Call

P

AccGlobal

P

Cf

P

P

rim

P

P

rim

P

Call

P

CallSig

-LSB-

args

-LRB-

pattern

-RRB-

-RSB-

-LSB-

return

-LRB-

pattern

-RRB-

-RSB-

-LSB-

P

If

-RSB-

P

CallSig

call

-LRB-

type

f

unId

-LRB-

type

-RRB-

-RRB-

P

If

if

-LRB-

expr

-RRB-

-LSB-

P

If

-RSB-

P

AccGlobal

readGlobal

-LRB-

type

varId

-RRB-

-LSB-

value

-LRB-

pattern

-RRB-

-RSB-

-LSB-

P

If

-RSB-

writeGlobal

-LRB-

type

varId

-RRB-

-LSB-

value

-LRB-

pattern

-RRB-

-RSB-

-LSB-

size

-LRB-

pattern

-RRB-

-RSB-

-LSB-

P

If

-RSB-

P

Cf

controlflow

-LRB-

P

CallSigList

P

Cf

End

-RRB-

controlflowstar

-LRB-

P

CallSigList

P

Cf

End

-RRB-

P

CallSigList

P

CallSig

-LSB-

P

CallSigList

-RSB-

P

Cf

End

P

Call

P

AccGlobal

P

Acc

read

-LRB-

var

-RRB-

-LSB-

value

-LRB-

pattern

-RRB-

-RSB-

-LSB-

P

If

-RSB-

write

-LRB-

var

-RRB-

-LSB-

value

-LRB-

pattern

-RRB-

-RSB-

-LSB-

size

-LRB-

pattern

-RRB-

-RSB-

-LSB-

P

If

-RSB-

pattern

var

val

Figure

Pointcut

language

A

A

A

A

parallelism

A

a.A

recursive

definition

-LRB-

a

Rec

-RRB-

C

I

A

prefixing

C

I

a

end

of

sequence

-LRB-

a

Rec

-RRB-

C

I

STOP

halting

aspect

A

P

A

choice

Figure

Tiny

aspect

language

tive

as

long

as

the

following

one

in

the

sequence

does

not

match

Branching

i.e.

a

logical

or

between

two

primitive

aspects

can

be

introduced

in

a

sequence

by

the

operator

An

element

of

the

sequence

can

also

match

a

global

variable

of

the

base

program

and

accesses

to

its

local

aliases

as

soon

as

its

address

is

known

-LRB-

i.e.

a

previous

primitive

pointcut

has

already

bound

its

address

to

a

pointcut

variable

-RRB-

Hence

an

aspect

matching

accesses

can

not

start

a

sequence

Every

join

point

matching

the

first

primitive

pointcut

of

a

sequence

starts

a

new

instance

of

the

sequence

The

different

instances

are

matched

in

parallel

A

primitive

or

a

sequence

aspect

a

can

be

used

in

combination

with

an

expression

until

-LRB-

a

-RRB-

to

restrict

its

scope

In

this

case

once

a

join

point

has

been

matched

by

a

the

execution

of

a

proceeds

as

previously

described

until

a

matches

To

conclude

the

presentation

of

our

language

note

that

it

does

not

include

some

features

such

as

named

pointcuts

as

arguments

to

controlflows

and

conjunctive

terms

which

are

not

necessary

for

the

examples

we

considered

but

which

could

easily

be

added

-LRB-

As

an

aside

note

that

such

extensions

of

the

pointcut

language

may

affect

the

computability

of

advanced

algorithmic

problems

such

as

whether

a

pointcut

matches

some

part

of

any

base

program

-LSB-

-RSB-

-RRB-

Towards

a

formal

semantics

for

expressive

aspects

In

the

previous

sections

we

have

given

an

informal

semantics

of

our

aspect

language

We

now

illustrate

how

the

aspect

language

could

be

formally

defined

by

translating

one

of

the

example

aspects

into

formal

aspect

language

by

extension

of

that

used

in

the

formal

framework

of

-LSB-

-RSB-

The

original

formal

language

must

be

extended

in

order

to

deal

with

halting

aspects

an

unbounded

number

of

sequential

aspects

and

arbitrary

join

point

predicates

The

grammar

of

the

extension

our

tiny

aspect

language

is

defined

in

Figure

In

this

language

aspect

expressions

A

consists

of

parallel

combinations

of

aspects

C

is

a

join

point

predicate

-LRB-

similar

to

our

pointcut

language

-RRB-

expressed

as

a

conjunction

of

a

term

pattern

and

possibly

an

expression

from

the

constraint

logic

programming

language

CLP

-LRB-

R

-RRB-

-LSB-

-RSB-

An

aspect

A

is

either

A

recursive

definition

A

sequence

formed

using

the

prefix

operation

C

I

X

where

X

is

an

aspect

or

a

recursion

variable

and

I

a

piece

of

code

-LRB-

i.e.

an

advice

-RRB-

A

choice

construction

A

P

A

which

chooses

the

first

aspect

that

matches

a

join

point

-LRB-

the

other

is

thrown

away

-RRB-

If

both

match

the

same

join

point

A

is

chosen

A

parallel

composition

of

two

aspects

A

A

that

can

not

occur

in

choice

construction

A

halting

aspect

STOP

The

semantics

of

the

protocol

translation

aspect

-LRB-

from

TCP

to

UDP

-RRB-

is

given

in

Fig.

A

sequence

can

have

several

instances

This

is

translated

into

the

language

A

by

the

expression

a

which

starts

a

new

sequence

a

once

the

first

join

point

has

been

matched

and

continue

to

match

the

rest

of

the

sequence

in

progress

The

repetition

operator

is

translated

into

recursion

on

variable

the

a

The

branching

operator

is

translated

into

the

choice

operator

a

callJP

-LRB-

fd

socket

-LRB-

AF

INET

SOCK

STREAM

-RRB-

-RRB-

socket

-LRB-

AF

INET

SOCK

DGRAM

-RRB-

a

-LRB-

callJP

-LRB-

a

connect

-LRB-

fd

address

length

-RRB-

-RRB-

returnZero

-LRB-

-RRB-

a

callJP

-LRB-

b

close

-LRB-

fd

-RRB-

-RRB-

skip

STOP

P

callJP

-LRB-

c

read

-LRB-

fd

readBuffer

readLength

-RRB-

-RRB-

recvfrom

-LRB-

fd

readBuffer

readLength

address

length

-RRB-

a

P

callJP

-LRB-

d

write

-LRB-

fd

writeBuffer

writeLength

-RRB-

-RRB-

recvfrom

-LRB-

fd

writeBuffer

writeLength

address

length

-RRB-

a

Figure

Definition

of

the

protocol

translation

using

the

tiny

aspect

language

P.

Finally

the

last

primitive

aspect

of

the

sequence

occurs

as

the

first

aspect

of

a

choice

to

get

priority

over

the

join

points

read

and

write

because

of

the

Note

that

we

use

pattern

matching

in

A

and

that

an

overbar

marks

the

first

occurrence

of

a

variable

-LRB-

i.e.

its

definition

not

a

use

-RRB-

Note

that

formal

definitions

such

as

that

of

the

protocol

translation

aspect

precisely

define

several

important

issues

in

particular

when

new

instances

of

the

sequence

aspect

are

created

and

disambiguate

of

potentially

non-deterministic

situations

e.g.

when

two

pointcuts

of

consecutive

primitive

aspects

in

the

sequence

match

at

the

same

time

Arachne

is

built

around

two

tools

an

aspect

compiler

and

a

runtime

weaver

The

aspect

compiler

translates

the

aspect

source

code

into

a

compiled

library

that

at

weaving

time

directs

the

weaver

to

place

the

hooks

in

the

base

program

The

hooking

mechanisms

used

in

Arachne

are

based

on

improved

techniques

originally

developed

for

Dyner

-LSB-

-RSB-

These

techniques

allow

to

rewrite

the

binary

code

of

executable

files

on

the

fly

i.e.without

pausing

the

base

program

as

long

as

these

files

conform

to

the

mapping

defined

by

the

Unix

standard

-LSB-

-RSB-

between

the

C

language

and

assembly

language

Arachne

's

implementation

is

structured

as

an

open

framework

that

allows

to

experiment

with

new

kinds

of

join

points

and

pointcut

constructs

Another

important

difference

between

Arachne

and

Dyner

is

that

Dyner

requires

a

compile

time

preparation

of

the

base

program

whereas

Arachne

does

not

Hence

Arachne

is

totally

transparent

for

the

base

program

while

Dyner

is

not

The

Arachne

Open

Architecture

The

Arachne

open

architecture

is

structured

around

three

main

entities

the

aspect

compiler

the

instrumentation

kernel

and

the

different

rewriting

strategies

The

aspect

compiler

translates

the

aspect

source

code

into

C

before

compiling

it

Weaving

is

accomplished

through

a

command

line

tool

weave

that

acts

as

a

front

end

for

the

instrumentation

kernel

weave

relays

weaving

requests

to

the

instrumentation

kernel

loaded

in

the

address

space

of

the

program

through

Unix

sockets

Upon

reception

of

a

weaving

request

the

instrumentation

kernel

selects

the

appropriate

rewriting

strategies

referred

by

the

aspects

to

be

woven

and

instruments

the

base

program

accordingly

The

rewriting

strategy

consults

the

pointcut

analysis

performed

by

the

aspect

compiler

to

locate

the

places

where

the

binary

code

of

the

base

program

needs

to

be

rewritten

It

finally

modifies

the

binary

code

to

actually

tie

the

aspects

to

the

base

program

With

this

approach

the

Arachne

core

is

independent

of

a

particular

aspect

of

the

aspect

language

of

the

particular

processor

architecture

and

of

a

particular

base

program

In

fact

all

dependencies

to

aspect

language

implementation

are

limited

to

the

aspect

compiler

All

dependencies

to

the

operating

system

are

localized

in

the

instrumentation

kernel

and

finally

all

dependencies

to

the

underlying

hardware

architecture

are

modularized

in

the

rewriting

strategies

The

Arachne

aspect

compilation

process

The

aspect

compilation

scheme

is

relatively

straightforward

it

transforms

advices

into

regular

C

functions

Pointcuts

are

rewritten

as

C

code

driving

hook

insertions

into

the

base

program

at

weaving

time

There

are

however

cases

where

the

sole

introduction

of

hooks

is

insufficient

to

determine

whether

an

advice

should

be

executed

In

this

case

the

aspect

compiler

generates

functions

that

complement

the

hooks

with

dynamic

tests

on

the

state

of

the

base

program

These

dynamic

tests

are

called

residues

in

AspectJ

and

the

rewritten

instructions

within

the

base

program

the

shadow

-LSB-

-RSB-

Once

the

aspects

have

been

translated

into

C

the

Arachne

compiler

uses

a

legacy

C

compiler

to

generate

a

dynamically

linked

library

-LRB-

DLL

-RRB-

for

the

compiled

aspects

The

Arachne

weaving

process

From

a

user

viewpoint

the

Arachne

weave

and

deweave

command

line

programs

the

same

syntax

than

Dyner

's

version

They

both

take

two

arguments

The

first

identifies

the

process

to

weave

aspects

in

or

deweave

aspects

from

and

the

second

indicates

the

aspect

DLL

However

Arachne

can

target

potentially

any

C

application

running

on

the

machine

while

Dyner

was

limited

to

applications

compiled

with

it

running

on

the

machine

When

Arachne

's

weave

receives

a

request

to

weave

an

aspect

in

a

process

that

does

not

contain

the

Arachne

instrumentation

kernel

it

loads

the

kernel

in

the

process

address

space

using

standard

techniques

-LSB-

-RSB-

The

instrumentation

kernel

is

transparent

for

the

base

program

as

the

latter

can

not

access

the

resources

-LRB-

memory

and

sockets

essentially

-RRB-

used

by

the

former

Once

injected

the

kernel

creates

a

thread

with

the

Linux

system

call

clone

This

thread

handles

the

different

weaving

requests

Compared

to

the

POSIX

pthread

create

function

the

usage

of

clone

allows

the

instrumentation

thread

to

prevent

the

base

program

to

access

its

sockets

The

instrumentation

kernel

allocates

memory

by

using

side

effect

free

allocation

routines

-LRB-

through

the

Linux

mmap

API

-RRB-

Because

the

allocation

routines

are

side

effect

free

Arachne

's

memory

is

totally

invisible

to

the

base

program

It

is

up

to

the

aspect

to

use

Arachne

's

memory

allocation

routines

or

base

program

specific

allocation

functions

This

transparency

turns

out

to

be

crucial

in

our

experiments

Legacy

applications

such

as

Squid

use

dedicated

resource

management

routines

and

expect

any

piece

of

code

they

run

to

use

these

routines

Failures

will

result

in

an

application

crash

After

loading

an

aspect

the

instrumentation

kernel

rewrites

the

binary

code

of

the

base

program

These

rewriting

strategies

are

not

included

in

the

kernel

and

must

be

fetched

on

demand

by

each

loaded

aspect

Rewriting

strategies

Rewriting

strategies

are

responsible

for

transforming

the

binary

code

of

the

base

program

to

effectively

tie

aspects

to

shadow

rewriting

site

replaced

by

a

instruction

instruction

instruction

instruction

execution

flow

generated

at

aspect

compile

time

Aspect

DLL

Hooks

generated

at

weaving

time

jump

Binary

code

of

the

compiled

base

program

and/or

advices

Residue

-LRB-

dynamic

tests

-RRB-

Entry

hook

save

registers

Return

hook

Restore

registers

instruction

-LRB-

s

-RRB-

Relocated

tailored

updating

registers

Legacy

base

program

Figure

Generic

hook

operations

the

base

program

at

weaving

time

These

strategies

localize

Arachne

's

main

dependencies

to

the

underlying

hardware

architecture

In

general

rewriting

strategies

need

to

collect

information

about

the

base

program

These

information

typically

consist

of

the

addresses

of

the

different

shadows

their

size

the

symbol

-LRB-

i.e.function

or

global

variable

name

-RRB-

they

manipulate

their

length

etc.

In

order

to

keep

compiled

aspects

independent

from

the

base

program

this

information

is

gathered

on

demand

at

runtime

The

mapping

between

a

symbol

name

in

the

base

program

source

code

and

its

address

in

memory

is

inferred

from

linking

information

contained

in

the

base

program

executable

However

because

these

information

can

be

costly

to

retrieve

Arachne

collects

and

stores

it

into

meta-information

DLLs

these

DLLs

behave

as

a

kind

of

cache

and

lessen

the

problem

of

collecting

the

information

required

to

instrument

the

base

program

To

implement

our

aspect

language

Arachne

provides

a

set

of

eight

rewriting

strategies

that

might

eventually

use

each

other

Strategies

for

call

readGlobal

and

writeGlobal

In

Arachne

call

readGlobal

and

writeGlobal

allow

an

advice

to

be

triggered

upon

a

function

call

a

read

on

a

global

variable

or

a

write

respectively

While

the

implementation

of

readGlobal

and

writeGlobal

in

Arachne

is

close

to

the

one

in

Dyner

Arachne

implements

the

strategy

for

call

by

rewriting

function

invocations

found

in

the

base

program

Dyner

instead

rewrites

the

function

body

of

the

callee

On

the

Intel

architecture

function

calls

benefit

from

the

direct

mapping

to

the

call

assembly

instruction

that

is

used

by

almost

if

not

all

compilers

Write

and

read

accesses

to

global

variables

are

translated

into

instructions

using

immediate

hard

coded

addresses

within

the

binary

code

of

the

base

program

By

comparing

these

addresses

with

linking

information

contained

in

the

base

program

executable

Arachne

can

determine

where

the

global

variable

is

being

accessed

Therefore

those

primitive

pointcuts

do

not

involve

any

dynamic

tests

The

sole

rewriting

of

the

binary

base

program

code

is

enough

to

trigger

advice

and

residue

executions

at

all

appropriate

points

The

size

of

the

call

instruction

and

the

size

of

an

jump

-LRB-

jmp

-RRB-

instruction

are

the

same

Since

the

instruction

performing

an

access

to

a

global

variable

involves

a

hard

coded

address

instructions

that

read

or

write

a

global

Residues

-LRB-

i.e.

dynamic

tests

on

the

base

program

state

-RRB-

are

required

when

these

primitive

pointcuts

are

combined

with

conditional

pointcuts

or

when

pattern

matching

is

involved

variable

have

at

least

the

size

of

a

jmp

instruction

Hence

at

weaving

time

Arachne

rewrites

them

as

a

jmp

instruction

to

a

hook

Hooks

are

generated

on

the

fly

on

freshly

allocated

memory

As

shown

in

figure

hooks

contain

a

few

assembly

instructions

that

save

and

restore

the

appropriate

registers

before

and

after

an

advice

-LRB-

or

shadow

-RRB-

execution

A

generic

approach

is

to

have

hooks

save

the

whole

set

of

registers

then

execute

the

appropriate

residue

and/or

advice

code

before

restoring

the

whole

set

of

registers

finally

the

instructions

found

at

the

join

point

shadow

are

executed

to

perform

the

appropriate

side

effects

on

the

processor

registers

This

is

accomplished

by

relocating

the

instructions

found

at

the

join

point

shadow

Relocating

the

instructions

makes

the

rewriting

strategies

handling

read

and

write

access

to

global

variable

independent

from

the

instruction

generated

by

the

compiler

to

perform

the

access

The

limited

number

of

instructions

used

to

invoke

a

function

allows

Arachne

's

rewriting

strategy

to

exploit

more

efficient

relo-cation

free

hooks

Strategies

for

controlflow

and

controlflowstar

Every

time

a

C

function

is

called

the

Linux

runtime

creates

an

activation

record

on

the

call

stack

-LSB-

-RSB-

Like

Dyner

Arachne

's

implementation

of

the

rewriting

strategy

for

controlflow

uses

the

most

deeply

nested

function

call

-LRB-

or

global

read

or

write

access

-RRB-

in

the

control

flow

pointcut

as

shadow

This

shadow

triggers

a

residue

This

residue

uses

the

activation

record

's

chaining

to

check

whether

the

remaining

function

calls

of

the

control

flow

are

on

the

call

stack

maintained

by

the

Linux

runtime

An

appropriate

usage

of

hashtables

that

store

the

linking

information

contained

in

the

base

program

executables

can

thereby

decrease

the

cost

of

determining

if

a

specific

function

is

the

caller

of

another

to

a

pointer

comparison

Therefore

the

residue

for

a

controlflow

with

n

directly

nested

functions

implies

exactly

n

pointer

comparisons

However

the

residue

worst

case

runtime

for

the

indirect

control

flow

operator

controlflowstar

that

allows

for

not

directly

nested

functions

is

proportional

to

the

base

program

stack

depth

Strategies

for

read

and

write

read

and

write

are

new

join

points

not

included

in

Dyner

that

have

been

added

to

the

latest

version

of

Arachne

Their

implementation

relays

on

a

page

memory

protection

as

allowed

by

the

Linux

operating

system

interface

-LRB-

i.e.

mprotect

-RRB-

and

the

Intel

processor

specifications

-LSB-

-RSB-

A

read

or

write

pointcut

triggers

a

residue

to

relocate

the

bound

variable

into

a

memory

page

that

the

base

program

is

not

allowed

to

access

and

adds

a

dedicated

signal

handler

Any

attempt

made

by

the

base

program

to

access

the

bound

variable

identified

will

then

trigger

the

execution

of

the

previously

added

signal

handler

This

handler

will

then

inspect

the

binary

instruction

trying

to

access

the

protected

page

to

determine

whether

it

was

a

read

or

a

write

access

before

eventually

executing

the

appropriate

advice

Strategies

for

seq

Like

read

and

write

seq

is

a

new

language

feature

of

Arachne

Dyner

offers

no

equivalent

construct

Arachne

's

rewriting

strategy

of

this

operator

associates

a

linked

list

to

About

instruction

mnemonics

can

directly

manipulate

a

global

variable

This

corresponds

to

more

than

one

thousand

opcodes

every

stage

inside

the

sequence

except

the

last

one

Each

stage

in

a

sequence

triggers

a

residue

that

updates

these

linked

lists

to

reflect

state

transitions

of

currently

matching

execution

flows

Upon

matching

of

the

first

pointcut

of

the

first

primitive

aspect

in

the

seq

a

node

is

allocated

and

added

to

the

associated

linked

list

This

node

contains

a

structure

holding

variables

shared

among

the

different

pointcuts

within

the

sequence

Once

a

join

point

matches

a

pointcut

of

an

primitive

aspect

denoting

a

stage

in

the

sequence

Arachne

consults

every

node

in

the

linked

list

associated

with

the

previous

stage

and

executes

the

corresponding

advice

Arachne

eventually

updates

the

node

and

in

the

absence

of

a

moves

it

to

the

list

associated

with

the

currently

matched

pointcut.If

the

matching

pointcut

corresponds

to

the

end

of

the

sequence

structures

are

not

moved

into

another

list

but

freed

Our

aspect

compiler

includes

an

optimization

where

structures

are

allocated

from

a

resizable

pool

and

upon

a

sequence

termination

structures

are

not

freed

but

returned

to

the

pool

Arachne

limitations

Aggressive

optimizations

of

the

base

program

might

prevent

Arachne

to

seamlessly

weave

aspects

Two

optimizations

are

not

yet

supported

by

Arachne

First

if

the

compiler

inlines

a

function

in

another

one

within

the

binary

code

of

the

base

program

the

Arachne

weaver

will

fail

to

properly

handle

pointcuts

referring

to

that

function

Second

control

flow

pointcuts

are

based

on

the

chaining

of

activation

records

On

the

architecture

in

leaf

functions

optimizing

compilers

sometimes

do

not

maintain

this

chaining

to

free

one

register

for

the

rest

of

the

computation

This

however

has

not

been

a

problem

during

our

experiments

as

we

used

the

open

source

C

compiler

gcc

Arachne

supports

two

of

the

three

optimization

levels

proposed

by

gcc

Stripping

that

removes

linking

information

and

aggressive

optimizations

that

break

the

interoperability

between

compilers

and/or

debuggers

are

incompatible

with

Arachne

In

practice

Arachne

can

be

used

on

applications

compiled

like

squid

with

two

of

the

three

gcc

optimization

level

Aspect-oriented

solutions

will

be

used

if

the

aspect

sys-tem

's

language

is

expressive

enough

and

if

the

aspect

system

overhead

is

low

enough

for

the

task

at

hand

The

purpose

of

this

section

is

to

study

Arachne

's

performance

We

first

present

the

speed

of

each

Arachne

language

construct

and

compare

it

to

similar

C

language

constructs

We

then

study

the

overhead

of

extending

Squid

with

a

prefetching

policy

This

case

study

shows

that

even

if

the

cost

of

some

Arachne

aspect

language

constructs

might

be

high

compared

to

C

language

constructs

this

overhead

is

largely

amortized

in

real

applications

Evaluation

of

the

language

constructs

This

performance

evaluation

focuses

on

studying

the

cost

of

each

construct

of

our

aspect

language

To

estimate

the

cost

for

each

construct

of

our

aspect

language

we

wrote

an

aspect

using

this

construct

that

behaves

as

an

interpreter

of

In

case

the

previous

stage

pointcut

was

used

with

a

star

Arachne

examines

nodes

from

linked

list

associated

with

the

last

two

previous

stages

and

so

on

until

a

not

starred

primitive

aspect

in

the

sequence

is

reached

Execution

times

-LRB-

cycles

-RRB-

Arachne

Native

Ratio

call

seq

cflow

readGlobal

read

Table

Speed

of

each

language

construct

used

to

interpret

the

base

program

compared

to

a

native

execution

the

base

program

For

example

to

study

the

performance

of

readGlobal

we

wrote

an

aspect

whose

action

returns

the

value

of

the

global

variable

referred

in

the

pointcut

i.e.

we

wrote

aspects

behaving

like

the

base

program

For

each

of

these

aspects

we

compare

the

time

required

to

perform

the

operation

matching

the

pointcut

in

case

the

operation

is

interpreted

by

the

woven

aspect

with

the

time

required

to

carry

out

the

operation

natively

-LRB-

without

the

woven

aspect

-RRB-

For

example

to

study

the

performance

of

readGlobal

we

first

evaluate

the

time

needed

to

retrieve

the

global

variable

value

through

the

code

generated

by

the

C

compiler

gcc

without

any

aspect

woven

and

compare

this

value

to

the

time

needed

to

retrieve

the

global

variable

value

through

the

aspect

once

it

has

been

woven

in

the

base

program

We

express

our

measurements

as

a

ratio

between

these

two

durations

to

abstract

from

the

experimentation

platform

This

approach

requires

the

ability

to

measure

short

periods

of

time

For

instance

a

global

variable

value

is

usually

retrieved

-LRB-

readGlobal

in

our

aspect

language

-RRB-

in

a

single

clock

tick

Since

standard

time

measurement

APIs

were

not

precise

enough

our

benchmarking

infrastructure

relies

on

the

rdtsc

assembly

instruction

-LSB-

-RSB-

This

instruction

returns

the

number

of

clock

cycles

elapsed

since

power

up

The

Pentium

processor

has

the

ability

to

dynamically

reorder

the

instructions

it

executes

To

ensure

the

validity

of

our

measurement

we

thus

insert

mfence

instructions

in

the

generated

code

whose

execution

speed

is

being

measured

An

mfence

forces

the

preceding

instructions

to

be

fully

executed

before

going

on

The

pipeline

mechanism

in

the

Pentium

processor

entails

that

the

speed

of

a

piece

of

assembly

code

depends

from

the

preceding

instructions

To

avoid

such

hidden

dependencies

we

place

the

operation

whose

execution

time

is

being

measured

in

a

loop

We

use

gcc

to

unroll

the

loop

at

compile

time

and

we

measure

the

time

to

execute

the

complete

loop

This

measure

divided

by

the

number

of

loop

repetitions

yields

an

estimation

of

the

time

required

to

execute

the

operation

The

number

of

times

the

loop

is

executed

is

chosen

after

the

relative

variations

of

the

measures

i.e.

we

increased

the

number

of

repetitions

until

ten

runs

yields

an

average

relative

variation

not

exceeding

To

check

the

correctness

of

our

experimental

protocol

we

measured

the

time

needed

to

execute

a

nop

assembly

instruction

that

requires

one

processor

cycle

according

to

the

Intel

specification

The

measures

of

nop

presented

a

relative

variation

of

Table

summarizes

our

experimental

results

Using

the

aspect

language

to

replace

a

function

that

returns

immediately

is

only

times

slower

than

a

direct

aspect-less

call

to

that

empty

function

Since

the

aspect

compiler

packages

advices

as

regular

C

functions

and

because

a

call

pointcut

involves

no

residue

this

good

result

is

not

surprising

When

Controlflow

Cycles

Cycles

Cycles

Cycles

Cycles

Ratio

with

a

normal

function

call

Number

of

imbricated

calls

Ratio

with

calls

Number

of

matching

instances

Cycles

Cycles

Cycles

Cycles

Sequence

Ratio

Cycles

Figure

controlflow

seq

and

read

performances

an

access

to

a

global

variable

is

replaced

by

an

advice

execution

the

hooks

generated

by

the

rewriting

strategy

need

to

prepare

the

processor

to

call

the

advice

function

This

increases

the

time

spent

in

the

hooks

In

addition

while

an

access

to

a

global

variable

is

often

performed

by

a

single

instruction

an

empty

function

is

often

composed

of

four

instructions

Hence

the

relative

cost

of

an

aspect

triggered

upon

a

global

variable

access

and

a

direct

aspect-less

access

to

a

global

variable

is

slightly

higher

than

the

corresponding

ratio

for

functions

A

seq

of

three

invocations

of

empty

functions

is

only

time

slower

than

the

direct

aspect-less

three

successive

functions

calls

Compared

to

the

pointcuts

used

to

delimit

the

different

stages

the

seq

overhead

is

limited

to

a

few

pointer

exchanges

between

the

linked

lists

holding

the

bound

variable

On

Intel

global

variable

accesses

benefit

from

excellent

hardware

support

In

the

absence

of

aspects

a

direct

global

variable

read

is

usually

carried

out

in

a

single

unique

cycle

To

trigger

the

advice

execution

the

Arachne

runtime

has

to

save

and

restore

the

processor

state

to

ensure

the

execution

co-herency

as

advices

are

packaged

as

regular

C

functions

-LRB-

see

also

-RRB-

It

is

therefore

not

surprising

that

a

global

variable

readGlobal

appears

as

being

times

slower

than

a

direct

aspect-less

global

variable

read

read

performance

can

be

accounted

in

the

same

way

in

the

absence

of

aspect

local

variables

are

accessed

in

a

single

unique

cycle

The

signal

mechanism

used

in

the

read

requires

that

the

operating

system

detects

the

base

program

attempt

to

read

into

a

protected

memory

page

before

locating

and

triggering

the

signal

handler

set

up

by

Arachne

as

shown

in

Such

switches

to

and

from

kernel

space

remain

slow

Using

read

to

read

a

local

variable

is

times

slower

than

retrieving

the

local

variable

value

directly

without

aspects

seq

and

controlflow

can

refer

to

several

points

in

the

execution

of

the

base

program

-LRB-

i.e.

different

stages

for

seq

and

different

function

invocations

for

the

controlflow

-RRB-

The

runtime

of

these

pointcuts

grows

linearly

with

the

number

of

execution

points

they

refer

to

and

with

the

number

of

matching

instances

Figure

summarizes

a

few

experimental

results

for

controlflow

and

seq

proving

these

points

Case

Study

on

a

real

application

Since

depending

on

the

aspect

construct

used

interpreting

the

base

program

with

aspects

can

slow

it

down

by

a

factor

ranging

between

and

we

studied

Arachne

's

performance

on

a

real

world

application

the

Web

cache

Squid

Arachne

Manual

Diff

-LRB-

-RRB-

Throughput

-LRB-

request/s

-RRB-

Response

Time

-LRB-

ms

-RRB-

Miss

response

time

-LRB-

ms

-RRB-

Hit

response

time

-LRB-

ms

-RRB-

Hit

ratio

Errors

Table

Performances

comparison

between

manual

modification

and

Arachne

for

prefechting

policy

integration

in

Squid

We

extended

Squid

with

a

prefetching

policy

-LSB-

-RSB-

As

described

in

section

we

implemented

this

policy

as

a

set

of

aspects

and

made

a

second

implementation

of

this

policy

by

editing

the

Squid

source

code

and

recompiling

it

This

section

compares

the

performance

of

these

two

implemen-tations

using

standard

Web

cache

performance

indicators

throughput

response

time

and

hit

ratio

Obtaining

access

traces

adequate

to

study

a

Web

cache

performance

is

difficult

The

trace

must

be

long

enough

to

fill

the

cache

Due

to

privacy

issues

traces

are

usually

not

publicly

available

Since

traces

do

not

include

the

content

of

the

accessed

pages

these

pages

must

be

downloaded

again

In

the

meantime

the

page

contents

may

have

changed

and

even

the

URLs

may

have

disappeared

Instead

of

traces

we

based

our

evaluation

on

Web

Polygraph

-LSB-

-RSB-

Polygraph

is

a

benchmarking

tool

developed

by

the

Squid

team

and

featuring

a

realistic

HTTP

and

SSL

traffic

generator

and

a

flexible

content

simulator

We

filled

up

the

cache

and

simulated

a

one

day

workload

with

its

two

request

rate

peaks

observed

in

real

life

environments

-LSB-

-RSB-

Table

shows

results

of

our

simulation

Measures

have

been

made

during

the

two

request

peaks

The

hit

time

and

the

miss

time

time

needed

to

deliver

a

document

present

respectively

not

present

in

the

cache

are

very

similar

It

shows

that

differences

are

imperceptible

between

the

version

of

Squid

extended

by

Arachne

and

the

one

extended

manually

-LRB-

less

than

-RRB-

Hence

even

if

the

cost

of

Arachne

's

aspect

language

constructs

might

seem

high

they

are

largely

amortized

in

real

applications

To

give

a

typical

example

observed

on

our

experimental

platform

in

case

of

a

cache

hit

a

MB

page

was

retrieved

in

a

single

second

the

time

spent

in

prefetching

advices

amounted

to

sec

and

the

time

spent

within

Arachne

to

execute

the

hooks

and

dynamic

tests

to

sec

In

a

miss

case

on

the

average

a

client

retrieved

the

same

page

in

seconds

sec

were

spent

in

the

advices

and

sec

within

Arachne

itself

Our

work

is

directly

related

to

other

aspect

weavers

for

C

approaches

for

expressive

aspect

languages

and

dynamic

weaving

in

particular

for

C

In

this

section

we

consider

related

work

in

each

of

these

fields

in

turn

Apart

from

Dyner

and

Arachne

there

are

few

aspect

weavers

for

C

-LRB-

or

even

C

like

languages

-RRB-

some

noteworthy

exceptions

are

AspectC

-LSB-

-RSB-

-LRB-

no

available

implementation

-RRB-

AspectC

and

-LSB-

-RSB-

All

of

these

rely

on

source-code

transformation

and

thus

can

not

apply

aspects

to

running

C

applications

as

required

by

the

applications

we

consider

Furthermore

of

these

systems

provides

explicit

support

for

aspects

over

join

point

sequences

There

is

quite

a

large

body

of

work

now

on

the

notion

of

expressive

aspect

languages

where

more

expressive

typically

compares

to

w.r.t.

AspectJ

's

pointcut

and

advice

models

Our

work

has

been

inspired

by

Event-based

AOP

-LSB-

-RSB-

which

aims

at

the

definition

of

pointcuts

in

terms

of

arbitrary

relations

between

events

Nevertheless

many

other

approaches

to

expressive

aspect

languages

exist

e.g.

data-flow

relations

-LSB-

-RSB-

logic

programming

-LSB-

-RSB-

process

algebras

-LSB-

-RSB-

graphs

-LSB-

-RSB-

and

temporal

logics

-LSB-

-RSB-

have

all

been

proposed

as

a

basis

for

the

definition

of

expressive

aspect

languages

However

few

of

these

encompass

dynamic

weaving

and

only

the

latter

has

been

applied

to

C

code

under

efficiency

considerations

similar

to

our

setting

Dynamic

weaving

is

commonly

realized

in

Java

through

preprocessing

at

load-time

like

-LSB-

-RSB-

or

through

the

JVM

Debugging

Interface

-LSB-

-RSB-

These

tools

rely

on

bytecode

rewriting

techniques

have

typically

limited

expressivity

-LRB-

some

do

not

support

field

accesses

-RRB-

and

incur

a

huge

performance

overhead

Dynamic

weaving

through

modification

at

runtime

is

found

infrequently

for

compiled

languages

An

exception

for

Java

is

JasCo

-LSB-

-RSB-

whose

most

recent

version

-LRB-

-RRB-

supports

dynamic

weaving

through

the

new

instrumentation

API

of

Java

Many

instrumentation

techniques

have

been

proposed

to

rewrite

binary

code

on

the

fly

In

these

approaches

difficulty

issues

range

from

the

complexity

to

rewrite

binary

code

to

the

lack

of

a

well-defined

relationship

between

source

code

and

the

compiler

generated

binary

code

Hence

many

approaches

work

on

an

intermediate

representation

of

the

binary

code

and

source

language

-LSB-

-RSB-

Producing

this

representation

first

and

then

regenerating

the

appropriate

binary

executable

code

has

proven

to

be

costly

both

in

terms

of

memory

consumption

and

in

CPU

time

A

few

other

approaches

have

considered

a

direct

rewriting

of

the

binary

code

at

runtime

Dyninst

-LSB-

-RSB-

and

dynamic

probes

-LSB-

-RSB-

allow

programmers

to

modify

any

binary

instruction

belonging

to

an

executable

Dyninst

however

relies

on

the

Unix

debugging

API

ptrace

ptrace

allows

a

third

party

process

to

read

and

write

the

base

program

memory

It

is

however

highly

inefficient

before

using

ptrace

the

third

party

process

has

to

suspend

the

execution

of

the

base

program

and

resume

its

execution

afterwards

In

comparison

Arachne

uses

ptrace

at

most

once

to

inject

its

kernel

DLL

into

the

base

program

process

In

addition

Dyninst

does

not

free

the

programmer

from

dealing

with

low

level

details

For

example

it

seems

difficult

to

trigger

an

advice

execution

upon

a

variable

access

with

Dyninst

the

translation

from

the

variable

identifier

to

an

effective

address

is

left

to

the

user

Worse

Dyninst

does

not

grant

that

the

manipulation

of

the

binary

instructions

it

performs

will

succeed

Dyninst

uses

an

instrumentation

strategy

where

several

adjacent

instructions

are

relocated

This

is

unsafe

as

one

of

the

relocated

instructions

can

be

the

target

of

branching

instructions

In

comparison

Arachne

join

point

model

has

been

carefully

chosen

to

avoid

these

kind

of

issues

if

an

aspect

can

be

compiled

with

Arachne

it

can

always

be

woven

In

this

paper

we

have

discussed

three

different

crosscutting

concerns

which

are

typical

for

C

applications

using

OS-level

services

and

which

frequently

need

to

be

applied

at

runtime

We

have

motivated

that

such

concerns

can

be

expressed

as

aspects

and

have

defined

a

suitable

aspect

language

This

language

is

more

expressive

than

those

used

in

other

aspect

weavers

for

C

in

that

it

provides

support

for

aspects

defined

over

sequences

of

execution

points

as

well

as

for

variable

aliases

We

have

presented

an

integration

of

this

language

into

Arachne

a

weaver

for

runtime

weaving

of

aspects

in

C

applications

Finally

we

have

provided

evidence

that

the

integration

is

efficient

enough

to

apply

such

aspects

dynamically

to

high-performance

applications

in

particular

the

web

cache

squid

As

future

work

we

intend

to

investigate

the

suitability

of

the

proposed

aspect

language

for

other

C-applications

We

also

intend

to

investigate

Arachne

extension

to

the

C++

language

Indeed

object-oriented

programming

heavily

uses

protocol-based

interfaces

collaboration

-LRB-

hence

sequence

aspects

-RRB-

Along

with

its

open

architecture

extending

Arachne

to

support

C++

will

pave

the

way

to

a

relatively

language

independent

aspect

and

weaving

infrastructure

Finally

Arachne

's

toolbox

should

be

extended

with

support

for

aspect

interactions

-LRB-

e.g.

analyses

and

composition

operators

-RRB-

-LSB-

-RSB-

R.

A.

Aberg

J.

L.

Lawall

M.

S

udholt

G.

Muller

and

A.-F

L.

Meur

On

the

automatic

evolution

of

an

os

kernel

using

temporal

logic

and

AOP

In

Proceedings

of

Automated

Software

Engineering

-LRB-

ASE

-RRB-

pages

IEEE

-LSB-

-RSB-

American

National

Standards

Institute

ANSI/ISO/IEC

Programming

Languages

C.

American

National

Standards

Institute

Broadway

New

York

NY

USA

-LSB-

-RSB-

J.

H.

Andrews

Process-algebraic

foundations

of

aspect-oriented

programming

In

Proceedings

of

the

International

Conference

on

Metalevel

Architectures

and

Separation

of

Crosscutting

Concerns

volume

of

LNCS

Springer

Verlag

Sept.

-LSB-

-RSB-

M.

Arlitt

and

T.

Jin

A

workload

characterization

study

of

the

world

cup

web

site

IEEE

Network

-LRB-

-RRB-

May

-LSB-

-RSB-

U.

A

mann

and

A.

Ludwig

Aspect

weaving

by

graph

rewriting

In

U.

W.

Eisenecker

and

K.

Czarnecki

editors

Generative

Component-based

Software

Engineering

-LRB-

GCSE

-RRB-

Erfurt

Oct.

-LSB-

-RSB-

CERT

Carnegie

Mellon

University

Vulnerability

note

vu

Feb.

published

on

line

-LSB-

-RSB-

H.

Chen

and

P.

Mohapatra

Catp

A

context-aware

transportation

protocol

for

http

In

International

Workshop

on

New

Advances

in

Web

Servers

and

Proxy

Technologies

Held

with

ICDCS

-LSB-

-RSB-

S.

Chiba

and

K.

Nakagawa

Josh

An

open

AspectJ-like

language

In

Proceedings

of

the

third

international

conference

on

Aspect-oriented

software

development

pages

ACM

Press

Mar.

-LSB-

-RSB-

K.-I

Chinen

and

S.

Yamaguchi

An

interactive

prefetching

proxy

server

for

improvement

of

WWW

latency

In

Seventh

Annual

Conference

of

the

Internet

Society

-LRB-

INET

-RRB-

Kuala

Lumpur

June

-LSB-

-RSB-

I.

Cidon

A.

Gupta

R.

Rom

and

C.

Schuba

Hybrid

tcp-udp

transport

for

web

traffic

In

Proceedings

of

the

IEEE

International

Performance

Computing

and

Communications

Conference

-LRB-

IPCCC

-RRB-

pages

Feb.

-LSB-

-RSB-

S.

Clowes

Injectso

Modifying

and

spying

on

running

processes

under

linux

In

Black

hat

briefings

-LSB-

-RSB-

Y.

Coady

G.

Kiczales

M.

Feeley

and

G.

Smolyn

Using

AspectC

to

improve

the

modularity

of

Path-Specific

customization

in

operating

system

code

In

V.

Gruhn

editor

Proc

of

the

Joint

European

Software

Engeneering

Conference

and

ACM

SIGSOFT

Symposium

on

the

Foundation

of

Software

Engeneering

-LRB-

ESEC/FSE

-RRB-

volume

of

SOFTWARE

ENGINEERING

NOTES

pages

New

York

Sept.

ACM

Press

-LSB-

-RSB-

K.

de

Volder

Aspect-oriented

logic

meta

programming

In

P.

Cointe

editor

Meta-Level

Architectures

and

Reflection

International

Conference

on

Reflection

volume

of

LNCS

pages

Springer

Verlag

-LSB-

-RSB-

R.

Douence

P.

Fradet

and

M.

S

udholt

A

framework

for

the

detection

and

resolution

of

aspect

interactions

In

Proceedings

of

the

ACM

SIGPLAN/SIGSOFT

Conference

on

Generative

Programming

and

Component

Engineering

-LRB-

GPCE

-RRB-

volume

of

LLNCS

pages

Springer-Verlag

Oct.

-LSB-

-RSB-

R.

Douence

O.

Motelet

and

M.

S

udholt

A

formal

definition

of

crosscuts

In

Proceedings

of

the

International

Conference

on

Metalevel

Architectures

and

Separation

of

Crosscutting

Concerns

volume

of

LNCS

pages

Springer

Verlag

Sept.

-LSB-

-RSB-

E.

Hilsdale

and

J.

Hugunin

Advice

weaving

in

aspectj

In

Proceedings

of

the

international

conference

on

Aspect-oriented

software

development

pages

ACM

Press

-LSB-

-RSB-

J.

K.

Hollingsworth

B.

P.

Miller

M.

J.

R.

Goncalves

O.

Naim

Z.

Xu

and

L.

Zheng

MDL

A

language

and

compiler

for

dynamic

program

instrumentation

In

IEEE

Conference

on

Parallel

Architectures

and

Compilation

Techniques

-LRB-

PACT

-RRB-

pages

Nov.

-LSB-

-RSB-

Intel

Corportation

Intel

Architecture

Software

Developer

's

Manual

Intel

Corportation

-LSB-

-RSB-

V.

Issarny

M.

Ban

atre

B.

Charpiot

and

J.-M

Menaud

Quality

of

service

and

electronic

newspaper

The

Etel

solution

Lecture

Notes

in

Computer

Science

-LSB-

-RSB-

J.

Jaffar

S.

Michaylov

P.

J.

Stuckey

and

R.

H.

C.

Yap

The

clp

-LRB-

r

-RRB-

language

and

system

ACM

Trans

Program

Lang

Syst.

-LRB-

-RRB-

-LSB-

-RSB-

JasCo

home

page

-LSB-

-RSB-

R.

Jones

and

P.

Kelly

Backwards-compatible

bounds

checking

for

arrays

and

pointers

in

c

programs

In

M.

Kamkar

editor

Proceedings

of

the

Third

International

Workshop

on

Automatic

Debugging

volume

pages

May

-LSB-

-RSB-

A.

D.

Keromytis

Patch

on

Demand

Saves

Even

More

Time

IEEE

Computer

-LRB-

-RRB-

-LSB-

-RSB-

G.

Kiczales

J.

Lamping

A.

Menhdhekar

C.

Maeda

C.

Lopes

J.-M

Loingtier

and

J.

Irwin

Aspect-oriented

programming

In

M.

Ak

sit

and

S.

Matsuoka

editors

Proceedings

European

Conference

on

Object-Oriented

Programming

volume

pages

Jyv

askyl

a

Finland

June

-LSB-

-RSB-

K.

J.

Lieberherr

J.

Palm

and

R.

Sundaram

Expressiveness

and

complexity

of

crosscut

languages

Technical

Report

Northeastern

University

Sept.

-LSB-

-RSB-

H.

Masuhara

and

K.

Kawauchi

Dataflow

pointcut

in

aspect-oriented

programming

In

First

Asian

Symposium

on

Programming

Languages

and

Systems

-LRB-

APLAS

-RRB-

-LSB-

-RSB-

R.

J.

Moore

Dynamic

probes

and

generalised

kernel

hooks

interface

for

Linux

In

USENIX

editor

Proceedings

of

the

Annual

Linux

Showcase

and

Conference

Atlanta

October

Atlanta

Georgia

USA

Berkeley

CA

USA

USENIX

-LSB-

-RSB-

A.

Popovici

G.

Alonso

and

T.

Gross

Just-in-time

aspects

efficient

dynamic

weaving

for

Java

In

Proceedings

of

the

international

conference

on

Aspect-oriented

software

development

pages

Boston

Massachusetts

Mar.

ACM

Press

-LSB-

-RSB-

M.

Rabinovich

and

H.

Wang

DHTTP

An

efficient

and

cache-friendly

transfer

protocol

for

web

traffic

In

INFOCOM

pages

-LSB-

-RSB-

A.

Rousskov

and

D.

Wessels

High-performance

benchmarking

with

Web

Polygraph

Software

Practice

and

Experience

-LRB-

-RRB-

Feb.

-LSB-

-RSB-

O.

Ruwase

and

M.

S.

Lam

A

practical

dynamic

buffer

overflow

detector

In

Proceedings

of

the

Annual

Network

and

Distributed

System

Security

Symposium

Internet

Society

Feb.

-LSB-

-RSB-

M.

S

egura-Devillechaise

J.-M

Menaud

G.

Muller

and

J.

Lawall

Web

cache

prefetching

as

an

aspect

Towards

a

dynamic-weaving

based

solution

In

Proceedings

of

the

international

conference

on

Aspect-oriented

software

development

pages

Boston

MA

USA

Mar.

ACM

Press

-LSB-

-RSB-

O.

Spinczyk

A.

Gal

and

W.

Schroeder-Preikschat

AspectC

an

aspect-oriented

extension

to

the

C++

programming

language

In

Proceedings

of

the

Fortieth

International

Conference

on

Tools

Pacific

pages

Australian

Computer

Society

Inc.

-LSB-

-RSB-

A.

Srivastava

and

A.

Edwards

Vulcan

Binary

transformation

in

a

distributed

environment

Microsoft

Research

Tech

Rpt

-LSB-

-RSB-

U.

S.

L.

System

Unix

System

V

Application

Binary

Interface

Intel

Architecture

Processor

Supplement

Prentice

Hall

Trade

-LSB-

-RSB-

D.

Wessels

Squid

The

Definitive

Guide

O'Reilly

and

Associates

Jan.

-LSB-

-RSB-

J.

Wilander

and

M.

Kamkar

A

comparison

of

publicly

available

tools

for

dynamic

buffer

overflow

prevention

In

Proceedings

of

the

Network

and

Distributed

System

Security

Symposium

pages

San

Diego

California

February

operating system
buffer overflows
network protocol
arachne
aspect language
system applications
dynamic weaving
c applications
prefetching
binary code
web cache