* Xiao-Feng Li:
> 1. the GC design usually hopes to have continuous memory space. The
> dynamic heap increase and decrease may have difficulty to interact
> with OS so as to keep the GC heap continuous.
At least on Linux, you can mmap with PROT_NONE to reserve an address
range, and later populate
* Tim Ellison:
>> Hmm, I think I was wrong. The scenario I had on mind can only occur
>> if the client also sends some data which is still in transit when the
>> server closes the connection. In this case, the server sends an RST
>> when that data arrives, and some clients discard all pending th
* Tim Ellison:
> Thanks Florian, I need to go back and read Steven's more closely ;-) .
> I have no doubt you are correct, but have never seen a close overtake
> the data -- we should of course do it right.
Hmm, I think I was wrong. The scenario I had on mind can only occur
if the client also se
* Tim Ellison:
> Maybe I'm misunderstanding the flow of the test here.
>
> here's how I read it...
>
> Server SideClient Side
> ------
> 'server' listens on 1234
>'channel' connects
> 'server' accepts
> 'out' s
* Fernando Cassia:
> On 5/17/06, Florian Weimer <[EMAIL PROTECTED]> wrote:
>>
>>
>> It's still a very strange license with a lot of oddities. For
>> example, it does not allow end users to use Debian's versions for
>> cross-platform development
* Geir Magnusson, Jr.:
> First, they announced some kind of distribution-like agreement with
> Ubuntu, so that any Debian-based distro can easily install Java. It
> wasn't clear if they really are going to distribute Ubuntu w/ Java or
> just make it easy to install via apt.
Currently, it seems t
* Enrico Migliore:
> the code is a simple function that gets called 3 times.
There's an explicit check in GCC that prevents the removal of empty
loops (because they are sometimes used for their timing effect on
embedded targets, IIRC). Therefore, your test is bogus.
> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html - Yummy.
Soot and JCVM already implement this as well, IIRC. The problems Tim
mentioned are addressed by JCVM by relying on inlining to expose stack
allocation opportunities.
* Joel Neely:
> Typed, constrained object references vs. untyped, unconstrained
> pointers.
Yes, but at some point in the compilation process, you have to flatten
"safe" object references to "unsafe" machine addresses. You can defer
this to the last instant with typed assembly language, but I do
* Ben Laurie:
> So, it seems to me that when you say its easier to write secure code in
> Java than C what you really mean is that its easier to write code free
> of buffer overflows in Java than C.
>
> I can't think of _any_ other interesting security properties that Java
> has and C lacks. Am
> --- incubator/harmony/standard/site/velocity.log (added)
> +++ incubator/harmony/standard/site/velocity.log Mon Jun 13 11:53:48 2005
> @@ -0,0 +1,230 @@
> +Mon Jun 13 14:52:06 EDT 2005 [debug] AvalonLogSystem initialized using
> logfile 'velocity.log'
> +Mon Jun 13 14:52:06 EDT 2005 [info]
>
11 matches
Mail list logo
