"Robert M. Münch" wrote:

> Just a stupid question: How can I write a GC with D while D uses a GC?

You would have to define your own allocation routine.  You could write a mark-and-sweep routine that scans all of the area of memory you've allocated, and cleans up things that aren't used anymore.  Since you would always keep a pointer (in the GC code) to each block you've allocated, D would never clean it up until you "forgot" about it.

> Can I
> compile without GC support?

The GC can be disabled.  People have talked about removing the GC altogether; that is probably possible, though I don't think that there is an "official" way to do that yet.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

On Mon, 22 Jul 2002 06:58:00 -0700 Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote:

> You would have to define your own allocation routine.  You could write a mark-and-sweep routine that scans all of the area of memory you've allocated, and cleans up things that aren't used anymore.  Since you would always keep a pointer (in the GC code) to each block you've allocated, D would never clean
it
> up until you "forgot" about it.

But still, dynamic arrays will still be GCed. You also have to use operator new to create class instances, so these will also be GCed.

I think a GC can be written simply by rewriting Walter's GC, keeping the
interface, but changing the internals.

>> Can I
>> compile without GC support?
> 
> The GC can be disabled.  People have talked about removing the GC altogether; that is probably possible, though I don't think that there is an "official"
way
> to do that yet.

D philosophy is GC-centric. For example, you can frequently find an array or a pointer to memory allocated inside a function then returned from it... how would you handle it if there was no GC?

Pavel Minayev wrote:

> On Mon, 22 Jul 2002 06:58:00 -0700 Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote:
>
> > You would have to define your own allocation routine.  You could write a mark-and-sweep routine that scans all of the area of memory you've allocated, and cleans up things that aren't used anymore.  Since you would always keep a pointer (in the GC code) to each block you've allocated, D would never clean
> it
> > up until you "forgot" about it.
>
> But still, dynamic arrays will still be GCed. You also have to use operator new to create class instances, so these will also be GCed.

Right, a custom GC would require hooks throughout your code, making it ugly.

> I think a GC can be written simply by rewriting Walter's GC, keeping the interface, but changing the internals.

An intriguing solution!

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahcu7l$ggn$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ah1akd$1i42$1@digitaldaemon.com...
> >*snip*
> >
> > There are some negatives about Java too, however.
> > One of them is the overhead that comes with interpreted
> > languaged. And the sandbox model, although very good
> > for web applets and the like, is less suited for
> > 'normal' windowed applications.
>
> You are misinformed.
> Java is not an "interpreted language". Modern jvms use just-in-time
> compilation, though I wish they'd do depoy-time/install-time compilation.
> Anyone know why they don't? iirc MS-CLR does this.
> With "normal windowed applications" you are not restricted to a "sandbox
> model".
>
<SNIP>

Maybe I used the term wrong, sorry about that, English
is not my native language. What I meant by sandbox here,
is that you are shielded from the underlying system.

As far as I know, in Java, you cannot call system
functions, such as CreateWindowEx for Windows, or fork
for Unix. So in that respect, you *are* within a sandbox.

It is also difficult if not important, to talk directly
to a lot of hardware, although this is also the case for
a lot of OS'es. Also, you cannot use inline asm. I call
this sandboxed.

Ofcourse, the normal sandbox is not as strict as the
one used for web applets, where you cannot even write
a file to disk, but is still is a form of sandboxing.
Sandboxing is great in some occasions, but it can be
a big negative in other occasions too.

I have nothing against Java, actually I love it. It is
a really beautiful language. I was just explaining
differences between Java and D, and the 'sandboxing' of
Java is definitely a difference, and a negative in
some cases.

Also, Java *is* an interpreted language. When Java first
came out, Just In Time compilation wasn't even available.
Just because the JVM's got better, doesn't mean the
language changed...I like Java the language, I just
don't like Java the environment / Virtual Machine and
Java programs. That is the core of the problem, I don't
like most Java programs that I have encountered so I am
not easily inclined to write one myself. I did do some
Java programming though, enough to know that I love most
things about the language itself, especially the syntax
and the object model. This is what attracts me in D, it
'feels' like Java. :)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Walter" <walter@digitalmars.com> wrote in message news:ahgenb$rsj$1@digitaldaemon.com...
> *snip*
> My problem with the pascal (and modula) philosophy is that it left you
with
> no way around the type constraints imposed by the language. D tries to provide a safety net without a straight jacket.

Modula-3 allows unsafe casting. It's was designed as a systems programming
language.
In m3 there are safe and unsafe modules. Unsafe modules can have unsafe
features like casts and address manipulation.
It's pretty cool.

"Walter" <walter@digitalmars.com> wrote in message news:ahgenb$rsj$1@digitaldaemon.com...
>
> It's conservative. The source comes with the alpha compiler.

Is it all in the the dmd/src/phobos/gc2 directory?

"Walter" <walter@digitalmars.com> wrote in message news:ahgenb$rsj$1@digitaldaemon.com...
> > > Symantec did the first JIT for Java.
> > oops. I really wasn't sure. It was probably that ms had the fastest jvm there for a while.
>
> Well, no, Symantec's was faster, too <g>. (Microsoft had better marketing,
> though.)

Probably a vicious rumour :-)

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ahkfgd$mko$1@digitaldaemon.com...
> *snip*
>
> Maybe I used the term wrong, sorry about that, English
> is not my native language. What I meant by sandbox here,
> is that you are shielded from the underlying system.
>
> As far as I know, in Java, you cannot call system
> functions, such as CreateWindowEx for Windows, or fork
> for Unix. So in that respect, you *are* within a sandbox.

Got you. I agree with you that calling C functions directly is a good feature for D.

You can call CreateWindowEx or whatever from Java. Just dot directly
afaik. I think that Microsoft's Java implementation did allow you to do it
more or less directly - via JDirect. That got them in trouble with Sun and
hence we
have C# and dotnet.

> *snip*
>
> Also, Java *is* an interpreted language. When Java first
> came out, Just In Time compilation wasn't even available.
> Just because the JVM's got better, doesn't mean the
> language changed...I like Java the language, I just
> don't like Java the environment / Virtual Machine and
> Java programs. That is the core of the problem, I don't
> like most Java programs that I have encountered so I am
> not easily inclined to write one myself. I did do some
> Java programming though, enough to know that I love most
> things about the language itself, especially the syntax
> and the object model. This is what attracts me in D, it
> 'feels' like Java. :)

It's doesn't seem right to me to talk about an "interpreted language" in any case. A language definition probably shouldn't say anything about whether the implementation will interpret intermediate code or compile to native code. Languages can be designed with interpretation in mind, though. Fortunately, the Java designers had the foresight not to include features which make native compilation harder.

Calling Java an interpreted *language* is just ridculous.
Is C an interpreted language because some C interpreters exist?
You said yourself that the Java language didn't change when people started
inventing
JITs - so what about Java made it "interpreted"?

Cheers, Steve.

"Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahltmr$2akd$1@digitaldaemon.com...
>
<SNIP>
>
> It's doesn't seem right to me to talk about an "interpreted language" in any case. A language definition probably shouldn't say anything about whether the implementation will interpret intermediate code or compile to native code. Languages can be designed with interpretation in mind, though. Fortunately, the Java designers had the foresight not to include features which make native compilation harder.
>
> Calling Java an interpreted *language* is just ridculous.
> Is C an interpreted language because some C interpreters exist?
> You said yourself that the Java language didn't change when people started
> inventing
> JITs - so what about Java made it "interpreted"?
>
> Cheers, Steve.
>

I guess you are right about that...
Are there any native compilers for Java available?
That would be cool!


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

OddesE wrote:
> "Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message
> news:ahltmr$2akd$1@digitaldaemon.com...
> 
> <SNIP>
> 
>>It's doesn't seem right to me to talk about an "interpreted language" in
>>any case. A language definition probably shouldn't say anything about
>>whether the implementation will interpret intermediate code or compile
>>to native code. Languages can be designed with interpretation in mind,
>>though. Fortunately, the Java designers had the foresight not to include
>>features which make native compilation harder.
>>
>>Calling Java an interpreted *language* is just ridculous.
>>Is C an interpreted language because some C interpreters exist?
>>You said yourself that the Java language didn't change when people started
>>inventing
>>JITs - so what about Java made it "interpreted"?
>>
>>Cheers, Steve.
>>
> 
> 
> I guess you are right about that...
> Are there any native compilers for Java available?
> That would be cool!
> 
> 
For linux, there is the gcj compiler, I haven't looked at it in
a while, but you can check it out at

http://gcc.gnu.org/java/

I saw a speed comparison between the JVM and gcj, at the time
gcj was a little slower than the interpreted bytecode, I dunno
if it has improved much since then.

-Jon